Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Oct 2014 08:03:20 -0700] rev 22940
phases: inform transaction-related hooks that a phase was moved
We do not have enough information to provide finer data, but this is still
useful information.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 13 Oct 2014 14:52:38 -0700] rev 22939
test-bundle2: also test the argument of the changegroup hook
We also track execution of the changegroup hook. The important information here
is to make sure the information that the transaction was processing a bundle2 is passed to
hook. This will let most hooks disable themselves while waiting for the hook
concluding bundle2 processing (the one we discovered to be not called for
pull in the previous changesets).
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 13 Oct 2014 14:47:36 -0700] rev 22938
test-bundle2: test that we got appropriate hook called with appropriate data
We can notice that this transaction wide hook is only happening during push and
it is missing changegroup-related information. We'll want to fix this but this
is not what this patch is about.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Oct 2014 06:40:36 -0700] rev 22937
pull: use `stepsdone` instead of `todosteps`
The push process uses a `stepsdone` attribute instead of a `todosteps` one (with
the logic swapped). We unify the two process by picking the `stepsdone` version.
I feel like `stepsdone` better fits extensions that would want to extend the push
exchange process.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 27 Sep 2014 00:29:06 -0700] rev 22936
pull: make discovery phase extensible
We apply the same approach as for push and make the discovery extensible. There
is only one user in core right now, but we already know we'll need something
smarter for obsmarkers. In fact the evolve extension could use this to cleanly
extend discovery.
The main motivation for this change is consistency between push and pull.
Yuya Nishihara <yuya@tcha.org> [Tue, 14 Oct 2014 21:59:39 +0900] rev 22935
sshpeer: forward stdout of remote "hg init" to appropriate output channel
Otherwise, commandserver channel could be corrupted.