[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
repo.revs().)
> (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