[PATCH] 1321 (partial): run Python pretxnchangegroup hooks before disk flush

Matt Mackall mpm at selenic.com
Fri Jan 16 08:46:55 CST 2009


On Fri, 2009-01-16 at 07:58 -0600, Matt Mackall wrote:
> On Fri, 2009-01-16 at 13:14 +0100, Gilles Moris wrote:
> > On Fri January 16 2009 10:10:11 Doug Philips wrote:
> > > One of us is confused. If the changeset is not visible, how can 'pull' or 'incoming' or anything else see it?
> > > That is the beauty of the way the repo is updated, with the beauty mark/blemish being that the changeset might be rejected, but is still visible for pulling, etc.
> > > 
> > 
> > Hum! After checking, the pull is not possible during the transaction hook, as there is a lock on the repo.
> 
> Incorrect. There is a lock, but it has no effect on pull.
> 
> The Mercurial locking model is: writers lock to prevent conflict with
> other writers, readers have no locking whatsoever.
> 
> Instead readers synchronize with writers through a single monotonically
> increasing counter, updated at the very end of commit. This counter is
> better known as the revision number of tip.
> 
> This lets us have an unlimited number of simultaneous readers even when
> a commit is in progress.

I left out the important bit: to let the pretxnchangegroup hook work, we
*break* the locking rules.

We update the above counter -before- we've closed out the write
transaction. This lets things in the hook "see" the changes they might
object to, which has the side-effect of letting anyone who tries to pull
see them as well.

But it also means the "monotonic counter" might be seen going backwards
if the hook returns an error and we cancel the transaction. So iff
you're using the pretxnchangegroup hook, strange things may happen if
you allow readers.

-- 
http://selenic.com : development and support for Mercurial and Linux




More information about the Mercurial-devel mailing list