clone fails if target is locked [and a bit on I/O ordering rules]

Matt Mackall mpm at selenic.com
Tue Aug 16 18:03:48 CDT 2005


On Tue, Aug 16, 2005 at 05:20:13PM +0200, Thomas Arendsen Hein wrote:
> * Bryan O'Sullivan <bos at serpentine.com> [20050816 17:13]:
> > The fix is not to read-lock the cloned repository, but to have the
> > hardlink code honour the ordering rules.
> 
> In the following discussion Matt came to the conclusion that a lock
> is still necessary, because otherwise there may be file revisions in
> the .hg/data directory not pointed to by a manifest.
> 
> While this is not directly a problem for Mercurial, 'hg verify' will
> complain about this, because this may be a hint that something else
> went wrong. To not spoil the usefulness of this, cloning by
> hardlinking should obey and set a lock on the cloned and on the
> target repository.

The tip now contains a fix for this, which simply takes a lock.

We'll probably eventually want to make non-hardlinked clone use pull.
This will possibly be faster than a copy and is lock-free, which is
good for cloning a shared repo on NFS to your local disk.

-- 
Mathematics is the supreme nostalgia of our time.


More information about the Mercurial mailing list