Nesting locks

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


On Mon, 2010-12-13 at 13:41 -0500, Greg Ward wrote:
> 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.

Actually, I don't think they should. Valid nesting is all about context
and coherency. For instance, it makes sense for the lock that mq takes
when pushing 20 patches to nest with the individual locks taken when
committing those patches. Because those individual commit are keeping
the state cached in the repo object coherent, the upper level logic in
mq won't get confused.

But if we create two repo objects A and B pointing to the same repo, a
commit with A won't be reflected in B until we invalidate() it.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list