changegroup: use tr.hookargs when calling pretxnchangegroup hooks So that other parties using the transaction can put information in our hook calls.

addchangegroup: register data in tr.hookargs We are registering data related to the process into the transaction hook data. This lets other parties using the same transaction get informed of the addchangegroup result.

transaction: add a notion of hook arguments It is now possible to register parameters to be used when invoking hooks in this transaction. This will cope with the fact that bundle2 adds multiple data types in a single transaction. Do not expect any wide and consistent usages of this in the next release. This will be used by bundle2 experiments first. It will be made better for the release after.

bundle2: allow extensions to plug into the push process Extensions are offered functions to add parts and process their results.

bundle2: require both client and server to opt in Even if the server is bundle2-enabled, the client now has to opt-in in the config too.

bundle2: move bundle2 config option to section "experimental" We highlight the fact that this is experimental by moving it to an "experimental" section, and we match the config name with the server capability name `bundle2-exp`.

bundle2: move all parts into a `bx2` namespace All currently core parts are moved to a `bx2` namespace (for "bundle 2 experimental"). This should avoid conflicts between the final stable format and the one about to be released.

bundle2: rename server capability to bundle2-exp For the same reason, we advertise this bundle2 implementation and format as experimental. This will leave room for field testing in 3.0 but won't conflict with a stable implementation in 3.1.

bundle2: use HG2X in the header The current implementation of bundle2 is still very experimental and the 3.0 freeze is yesterday. The current bundle2 format has never been field-tested, so we rename the header to HG2X. This leaves the HG20 header available for real usage as a stable format in Mercurial 3.1. We won't guarantee that future mercurial versions will keep supporting this `HG2X` format.

bundle2: transmit capabilities to getbundle during pull Bundle2 capabilities of the client are sent to the server in the bundlecaps argument of `getbundle`.

bundle2: include client capabilities in the pushed bundle The necessary data is now included in the `replycaps` part.

bundle2: advertise bundle2 caps in server capabilities We can now retrieve them from the server during push. The capabilities are encoded the same way as in `replycaps` part (with an extra layer of urlquoting to escape separators).

bundle2: add bundle2caps dict on localrepo object This dictionary will hold bundle2-related capabilities.

bundle2: capabilities encoding

bundle2: extract capabilities decoding We'll need to reuse this in more places (at least pull and push).

bundle2: protect capabilities name and values with url quoting This lift limitations of the text based encoding.

bundle2: support for capabilities with values The capabilities attributes of `bundle20` is now a dictionary and the reply caps can encode capabilities with values.

bundle2: add capabilities support in `replycaps` part This part now contains a list of supported capabilities.

bundle2: adds a capabilities attribute on bundler20 This attribute conveys the capabilities supported by the destination of the bundle. It is used to decide which parts to include in the bundle. This is currently a set but will probably be turned into a dictionary to allow capabilities with values.

bundle2: include stderr when capturing handlers output We do not discriminate between stdout and stderr yet. But this will do for now.

ui: pushbuffer can now also capture stderr We need an easy way to capture both stderr and stdout during bundle2 processing of a remote bundle. This changeset adds simple changes to the `ui` class to make this possible. I expect the interface to change in future releases as bundle2 will probably want to distinguish stdout and stderr. The current change will, however, do for now.

bundle2: capture remote stdout while unbundling When a reply is built, the bundle processing will capture the output of each handler and sends it to the client in a dedicated part. As a side effect, this add a "remote: " prefix to destination output on local push. This is considered okay for now as: 1. bundle2 is still experimental, 2. Matt said he could be okay to change output for bundle2, 3. This keeps the implementation simple. This changeset does it for stdout only. stderr will be done in a future changeset.

bundle2: introduce `replycaps` part for on-demand reply The bundle2 processing does not create a bundle2 reply by default anymore. It is only done if the client requests it with a `replycaps` part. This part is called `replycaps` as it will eventually contain data about which bundle2 capabilities are supported by the client. We have to add a flag to the test command to control whether a reply is generated or not.

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.