[PATCH 0 of 6 REPHASE-VIEW] Phase exchange overpushkey

Matt Mackall mpm at selenic.com
Wed Oct 26 09:42:52 CDT 2011

On Wed, 2011-10-26 at 14:56 +0200, pierre-yves.david at logilab.fr wrote:
> Here is a series that add the phase.publish option and the ability to exchange
> phase boundary on pull and push. Please see the 4 notes bellow before reading
> the series
> (1) Listing remote phases roots instead of phases heads is much more efficient.
>     however using heads help other operation (as moving heads forward including
>     during push). I'll keep storing heads and computing root when necessary
>     until all usecase are written down. I may later decide to store root and
>     computes heads when necessary.

Note that this operation shouldn't be much harder than:

liquidroots = [c.rev() for c in
                 repo.set('roots(%ld:: - ::ld%', liquidroots, frozenheads)]

(I'm beginning to think we need a shorthand for that. Something like

> (2) Boundary are pushed nodes by nodes, this seems quite inefficient and pretty
>     bad transaction wise and hook executed when pushing to node N can't abort
>     push of N-1 node.

This will only be painful in pathological cases, I think.

Also, Peter started writing a batching extension to the wire protocol.

> (3) The addchangegroup method takign ownership of the transaction lock making is
>     complicated to execution phase code before the transaction is release but
>     after changeset have been made avaible. As the phase code needs several
>     variable only avaible for the context that call addchangegroup, my current
>     workaround build closure in calling context to be used by addchangegroup.
>     This will get worse once we have afterphasemove hooks

Yeah, we might have to refactor this substantially.

> (4) With the new peers code for wireprotocols, I did not find a way to handle
>     phase movement in the same transaction that addchangegroup. This seems
>     pretty bad.

The wire protocol intentionally avoids having a locking method. If you
look way back in history to the earliest ssh support, you'll find one
that we eventually stopped using. This is because a crashing client
leaves the server in a locked (and messed up) state.

But you raise a good point - it's not ideal for changesets to be
temporarily visible on the server in the wrong state.

Mathematics is the supreme nostalgia of our time.

More information about the Mercurial-devel mailing list