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.
More information about the Mercurial-devel