Nesting locks

Greg Ward greg at gerg.ca
Mon Dec 13 12:41:29 CST 2010


On Mon, Dec 13, 2010 at 1:13 PM, Matt Mackall <mpm at selenic.com> wrote:
> The locks themselves are not recursive, just the interface provided by a
> given repo object. In other words, you have to call repo.lock() on the
> same repo.

Ahhhh.  And I'm opening multiple shared clones, so I have distinct
repo objects that all point to the same store dir.  They *ought* to
share lock knowledge, but they don't.

I've hacked around this in my script: when opening the "source" repo
(working dir of the branch we're merging from), I lock() it.  Then I
open all the "target" repos and, for each one:

  * assert that repo.sharedpath == sourcerepo.sharedpath (i.e. people
    are following our recommended practice of using shared clones
    for maintenance work)

  * copy/borrow/steal the lock weakref from the "source" repo:

      repo._lockref = sourcerepo._lockref

Now all my shared clone repo objects share lock info, at least while
the lock is held.  And I plan to hold it for the lifetime of this
script, so I think I'm safe there.

This should do me for now.  Is this something localrepo could/should
do for me?  I don't see how unless we keep track of all the stores
opened in this process.

Greg


More information about the Mercurial-devel mailing list