- Apr 17, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Pierre-Yves David authored
We want extensions to be able to request extra parts.
-
Pierre-Yves David authored
We add a hook function to let extensions add parts to the bundle.
-
Pierre-Yves David authored
The wireprotocol command accepts arbitrary arguments, we are now passing such arguments down the call chain.
-
Pierre-Yves David authored
We call a dedicated hook right after closing the transaction. This will let people react to the transaction with all the information in hand. This hook is experimental and will not survive in future versions.
-
Pierre-Yves David authored
We call a dedicated hook right before closing the transaction. This will let people abort unbundling with all the information in hand. This hook is experimental and will not survive in future versions.
-
Pierre-Yves David authored
That way, hooks called during the unbundle process are aware that a bigger picture is going on.
-
Pierre-Yves David authored
So that other parties using the transaction can put information in our hook calls.
-
Pierre-Yves David authored
So that other parties using the transaction can put information in our hook calls.
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
Extensions are offered functions to add parts and process their results.
-
Pierre-Yves David authored
Even if the server is bundle2-enabled, the client now has to opt-in in the config too.
-
Pierre-Yves David authored
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`.
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
Bundle2 capabilities of the client are sent to the server in the bundlecaps argument of `getbundle`.
-
Pierre-Yves David authored
The necessary data is now included in the `replycaps` part.
-
Pierre-Yves David authored
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).
-
Pierre-Yves David authored
This dictionary will hold bundle2-related capabilities.
-
Pierre-Yves David authored
-
Pierre-Yves David authored
We'll need to reuse this in more places (at least pull and push).
-
Pierre-Yves David authored
This lift limitations of the text based encoding.
-
Pierre-Yves David authored
The capabilities attributes of `bundle20` is now a dictionary and the reply caps can encode capabilities with values.
-
Pierre-Yves David authored
This part now contains a list of supported capabilities.
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
We do not discriminate between stdout and stderr yet. But this will do for now.
-
Pierre-Yves David authored
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.
-
- Apr 16, 2014
-
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
Explicit is better than implicit.
-
- Feb 28, 2014
-
-
Mads Kiilerich authored
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.
-
Lucas Moscovicz authored
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.
-
- Feb 24, 2014
-
-
Mads Kiilerich authored
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.
-
- Apr 17, 2014
-
-
Mads Kiilerich authored
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.
-
Katsunori FUJIWARA authored
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.
-
Katsunori FUJIWARA authored
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.
-