Philip observed today that, since 'hotcopy' copies the $REPOS/db/locks/???/*
files using a simple svn_io_copy_dir_recursively(), the correctness of
the copy is not guaranteed if locks are being added/removed while the
hotcopy is ongoing: the hotcopy might contain only an arbitrary subset
of the path-prefix-digest-files. (It might contain any subset of the
three digest files md5("/"), md5("/trunk/iota"), md5("/trunk"). The
lock removal removes/updates those files in depth-first order.)
So, a few questions:
1. 'svn lock ^/trunk/iota' creates an md5("/trunk") digest file. That
digest file is not referenced by the md5("/") digest file; both of
these digest files refer only and directly to the md5("/trunk/iota")
digest file.
Does the md5("/trunk") digest file have to be preserved in a hotcopy?
Given that it is unreferenced, under what conditions would it be read
--- when the reader is pre-1.7?
2. Given that the md5("/") digest file refers to iota's digest file
directly, doesn't that mean that the md5("/") digest file will
refer *every* locked file's digest file? I'm concerned about the
efficiency of this arrangement.
3. What's a reasonable strategy to hotcopy the locks?
I've started on a patch that uses walk_digest_files() (I modified
that function today), but currently that patch simply does a walk
starting at the digest file md5("/"), and consequently it misses
copying the unreferenced digest file md5("/trunk").
