[PATCH 4 of 4] bundle2: no longer use 'retractboundary' in updatephases

Sean Farley sean at farley.io
Wed Jul 12 23:29:12 EDT 2017


Boris Feld <boris.feld at octobus.net> writes:

> # HG changeset patch
> # User Boris Feld <boris.feld at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170712/c53ae89c/attachment.sig>


More information about the Mercurial-devel mailing list