Nesting locks

Matt Mackall mpm at selenic.com
Mon Dec 13 12:13:17 CST 2010


On Mon, 2010-12-13 at 12:51 -0500, Greg Ward wrote:
> Hi all --
> 
> I'm writing a script that does multiple merges and commits in various
> working dirs, all of which are shared clones of the same repo.  The
> goal is to automate a common bit of workflow for us, which is to fix a
> bug in (say) branch 3.7, then merge to 3.8, 3.9, 4.0, 4.1, and trunk.
> 
> It seems like a really good idea for my script to lock the shared repo
> that all of these working dirs point to.  But that causes problems
> when I try to commit anything: repo.commit() tries to get a lock and
> fails because the repo is already locked.  But it's locked by *this
> process*!  (I'm doing this entirely through the Python API in a single
> process, not as a shell script.  It should be faster, it gives me more
> control, and I want it to work on Windows.)
> 
> It looks like Mercurial's locking mechanism is happy to let you nest
> locks if you use the same lock object, but not if you use distinct
> objects in the same process -- which is what happens if two separate
> bits of code call repo.lock().  ;-(  Am I missing something?  Is there
> a good way to do this?

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.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list