Sun, 12 Oct 2014 08:29:31 -0700 bookmarks: inform transaction-related hooks that some bookmarks were moved
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Oct 2014 08:29:31 -0700] rev 22941
bookmarks: inform transaction-related hooks that some bookmarks were moved We do not have enough information to provide any finer data, but this is still useful information.
Sun, 12 Oct 2014 08:03:20 -0700 phases: inform transaction-related hooks that a phase was moved
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.
Mon, 13 Oct 2014 14:52:38 -0700 test-bundle2: also test the argument of the changegroup hook
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).
Mon, 13 Oct 2014 14:47:36 -0700 test-bundle2: test that we got appropriate hook called with appropriate data
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.
Sun, 12 Oct 2014 06:40:36 -0700 pull: use `stepsdone` instead of `todosteps`
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.
Sat, 27 Sep 2014 00:29:06 -0700 pull: make discovery phase extensible
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.
Tue, 14 Oct 2014 21:59:39 +0900 sshpeer: forward stdout of remote "hg init" to appropriate output channel
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.
Wed, 03 Sep 2014 16:34:29 -0400 revlog: support importing censored file revision tombstones
Mike Edgar <adgar@google.com> [Wed, 03 Sep 2014 16:34:29 -0400] rev 22934
revlog: support importing censored file revision tombstones This change allows a revision log to not fail integrity checks when applying a changegroup delta (eg from a bundle) results in a censored file tombstone. The tombstone is inserted as-is, so future integrity verification will observe the tombstone. Deltas based on the tombstone will also remain correct. The new code path is encountered for *exactly* the cases where _addrevision is importing a tombstone from a changegroup. When committing a file containing the "magic" tombstone text, the "text" parameter will be non-empty and the checkhash call is not executed (and when committing, the node will be computed to match the "magic" tombstone text).
Tue, 14 Oct 2014 16:16:04 -0400 verify: report censored nodes if configured policy is abort
Mike Edgar <adgar@google.com> [Tue, 14 Oct 2014 16:16:04 -0400] rev 22933
verify: report censored nodes if configured policy is abort
Tue, 14 Oct 2014 15:46:16 -0400 context: handle censored data in an on-disk file context based on config
Mike Edgar <adgar@google.com> [Tue, 14 Oct 2014 15:46:16 -0400] rev 22932
context: handle censored data in an on-disk file context based on config Two possible behaviors are defined for handling censored data: abort, and ignore. When we ignore censored data we return an empty file to callers requesting the file data.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip