Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 17 Apr 2014 11:44:49 -0400] rev 21136
bundle2: support for capabilities with values
The capabilities attributes of `bundle20` is now a dictionary and the reply caps
can encode capabilities with values.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 17 Apr 2014 11:32:30 -0400] rev 21135
bundle2: add capabilities support in `replycaps` part
This part now contains a list of supported capabilities.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 16 Apr 2014 23:55:59 -0400] rev 21134
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.
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.
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.
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.
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.
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.
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.
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.