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