Nesting locks

Greg Ward greg at
Mon Dec 13 11:51:37 CST 2010

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?

Thanks --


More information about the Mercurial-devel mailing list