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

[Martin von Zweigbergk]

On Wed, Jul 12, 2017 at 8:29 PM, Sean Farley <sean at farley.io> wrote:
>
> 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.

I feel like we should be able to replace the "targetphase=secret"
parameter by a "dontupdatephasesatall=true" parameter that will be set
when there's a phase-heads part in the bundle. Then there would be
only one phase update. I also feel like changegroup.apply() updating
phases should only be for legacy reasons, kind of how like phases and
bookmarks are exchanged via separate requests if they are not in the
bundle.

>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>