bundle2: use an official iterparts method to unbundle parts Explicit is better than implicit.

merge: with merge.preferancestor=*, run an auction with bids from ancestors The basic idea is to do the merge planning with all the available ancestors, consider the resulting actions as "bids", make an "auction" and automatically pick the most favourable action for each file. This implements the basic functionality and will only consider "keep" and "get" actions. The heuristics for picking the best action can be tweaked later on. By default it will only pass ctx.ancestor as the single ancestor to calculateupdates. The code path for merging with a single ancestor is not changed.

log: changed implementation to use graphlog code Now that revsets work in a lazy way, log code can be changed to parse every option into a revset and then evaluate it lazily. Now expressions like "hg log -b default -b ." are converted into a revset using the same code as graphlog.

context: introduce merge.preferancestor for controlling which ancestor to pick Multiple revisions can be specified in merge.preferancestor, separated by whitespace. First match wins. This makes it possible to overrule the default of picking the common ancestor with the lowest hash value among the "best" (introduced in 3605d4e7e618). This can for instance help with some merges where the 'wrong' ancestor is used. There will thus be some overlap between this and the problems that can be solved with a future 'consensus merge'. Mercurial will show a note like note: using 40663881a6dd as ancestor of 3b08d01b0ab5 and adfe50279922 alternatively, use --config merge.preferancestor=0f6b37dbe527 when the option is available, listing all the alternative ancestors.

context: tell when .ancestor picks one of multiple common ancestors heads Show a message like note: using 0f6b37dbe527 as ancestor of adfe50279922 and cf89f02107e5 So far this is just a warning - there is nothing the user can do to select another ancestor.

hgweb: align entries in "changelog" and "revisions" pages of "spartan" style Before this patch, each log entries in "changelog" and "revisions" pages of "spartan" style are not aligned by column, because: - each log entries are separated "<table>" entries, and - there are no fixed "width" information for each "<th>"/"<td>" entries This patch aligns entries in "changelog" and "revisions" pages of "spartan" style by: - adding 'label' class to '<th>' for 'age' information, and - setting 'width' of '<th class="label">' with fixed size 'class="age"' is not used for this purpose, because it is also used to set "bold" font-weight "16em" seems to be wide enough to show date information fully, when web browser disables (or doesn't support) javascript.

hgweb: show revisions and hashes gotten from changelog in "comparison" page Before this patch, revision numbers and hash values in "comparison" page are gotten from not changelog but filelog. Such filelog information is useful only for hgweb debugging, and may confuse users. This patch shows revision numbers and hash values gotten from changelog in "comparison" page.