Wed, 16 Apr 2014 23:18:27 -0400 bundle2: include stderr when capturing handlers output
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 16 Apr 2014 23:18:27 -0400] rev 21133
bundle2: include stderr when capturing handlers output We do not discriminate between stdout and stderr yet. But this will do for now.
Wed, 16 Apr 2014 23:36:57 -0400 ui: pushbuffer can now also capture stderr
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 16 Apr 2014 23:36:57 -0400] rev 21132
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.
Wed, 16 Apr 2014 14:22:24 -0400 bundle2: capture remote stdout while unbundling
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 16 Apr 2014 14:22:24 -0400] rev 21131
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.
Wed, 16 Apr 2014 14:09:35 -0400 bundle2: introduce `replycaps` part for on-demand reply
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 16 Apr 2014 14:09:35 -0400] rev 21130
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.
Wed, 16 Apr 2014 18:41:48 -0400 bundle2: use an official iterparts method to unbundle parts
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 16 Apr 2014 18:41:48 -0400] rev 21129
bundle2: use an official iterparts method to unbundle parts Explicit is better than implicit.
Fri, 28 Feb 2014 02:52:32 +0100 merge: with merge.preferancestor=*, run an auction with bids from ancestors
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Feb 2014 02:52:32 +0100] rev 21128
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.
Fri, 28 Feb 2014 15:10:56 -0800 log: changed implementation to use graphlog code
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 28 Feb 2014 15:10:56 -0800] rev 21127
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.
Mon, 24 Feb 2014 22:42:14 +0100 context: introduce merge.preferancestor for controlling which ancestor to pick
Mads Kiilerich <madski@unity3d.com> [Mon, 24 Feb 2014 22:42:14 +0100] rev 21126
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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip