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

[Chris Mason]

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
the files:

commit                  Clone
update file1
update file2
			link manifest
			link changeset
update manifest
update changeset
			link file1
			link file2

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:

commit                  Clone
update file1
update file2
			link manifest
			link changeset
update file3
update manifest
update changeset
			link file1
			link file2
			link file3

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
are correct.

-chris