clone fails if target is locked [and a bit on I/O ordering
mason at suse.com
Tue Aug 16 10:34:48 CDT 2005
On Tue, 16 Aug 2005 08:11:23 -0700
"Bryan O'Sullivan" <bos at serpentine.com> wrote:
> But the hardlinking code is doing the hardlinks willy nilly, and
> sometimes the lack of ordering means that the changeset or manifest
> point to bits of file that don't exist. This can only happen if the
> repo being cloned is being written during the clone.
> The fix is not to read-lock the cloned repository, but to have the
> hardlink code honour the ordering rules.
Lets consider some ordering options:
1) when hardlinking, we first link the changeset and manifest, and then
file1 and file2 now have revlinks pointing to the new commit, but the
changeset linked in does not. This won't pass hg verify.
2) When hardlinking, we first link the files and then the manifest and
then the changeset:
file3 now has a link pointing to the new commit, but the manifest and
changeset don't yet include that commit. This won't pass hg verify.
I think TAH just replied as well...we need the read lock to make things
correct, or we need a second pass to make sure the changeset/manifest
More information about the Mercurial