Boris Feld <boris.f...@octobus.net> writes: > # 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.
Nice, I like where this is going. If I understand correctly, we are no longer assuming bundles are draft, correct? This will open the door so that we can track phase change in a transaction (and I can thereby put that information into a hook) as well, right? If so, that's awesome and I'll queue these tomorrow if there's no objection.
signature.asc
Description: PGP signature
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel