# HG changeset patch # User Boris Feld <boris.f...@octobus.net> # Date 1499742361 -7200 # Tue Jul 11 05:06:01 2017 +0200 # Node ID 002ca6e17d6b53123c5ab4a4a46fb3f5d453e072 # Parent 5a2c6c050e33e4f2a571247f5d1e150a3ef1d295 # EXP-Topic tr.changes.phases bundle2: no longer use 'retractboundary' in updatephases
The new 'phase-heads' forced all added node to secret before advancing the boundary to work around the fact changesets were added as draft by default. This is no longer necessary since the changegroup part can now use the 'targetphase' parameter. Not doing this retract boundary call has a couple of advantages: * This makes implementing phases change tracking in the transaction much simpler since retract boundary can become a rare case. * Bundling secret changesets is not the norm. Exchange never does that and even for strip, the use-case is not common.Skipping the retract boundary will avoid useless work here. * Sending phase update on push can be simplified since we can rely on the behavior of 'cg.apply' for most of it. This means less phases update send for example. * We no longer needs to track and use the addednodes during unbundling. This make it possible to have multiple 'changegroup' and 'phase-heads' parts in the same bundle without them interfering with each others. The new part has not been part of any release yet so we do not offer backward compatibility yet. It is important to update this semantic before the 4.3 freeze happens. diff -r 5a2c6c050e33 -r 002ca6e17d6b mercurial/phases.py --- a/mercurial/phases.py Tue Jul 11 05:12:03 2017 +0200 +++ b/mercurial/phases.py Tue Jul 11 05:06:01 2017 +0200 @@ -448,10 +448,6 @@ def updatephases(repo, tr, headsbyphase, addednodes): """Updates the repo with the given phase heads""" - # First make all the added revisions secret because changegroup.apply() - # currently sets the phase to draft. - retractboundary(repo, tr, secret, addednodes) - # Now advance phase boundaries of all but secret phase for phase in allphases[:-1]: advanceboundary(repo, tr, phase, headsbyphase[phase]) _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel