C. Michael Pilato wrote on Fri, Nov 12, 2010 at 09:40:49 -0500:
> On 11/11/2010 04:25 PM, Daniel Shahaf wrote:
> > 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:
>
> Maybe, just maybe, you can find some of the information you seek in the
> history of http://subversion.tigris.org/issues/show_bug.cgi?id=3660. I had
> to study the FSFS lock storage and usage algorithms some time ago to fix a
> bug. (Though, don't expect to find hotcopy strategies there.)
Indeed, I don't find hotcopy strategies there, but I do find there
discussion on whether the FSFS locks directory should, in each
non-immediate ancestor of a locked file, a pointer to that file's digest
file or a pointer to the next-ancestor-in-the-chain (i.e., /trunk to
/trunk/A)'s digest file.
I guess this answers my original point (2) by "It has always been this
way". Following "if it ain't broken, don't fix it", I'll leave this bit
untouched until somebody complains (that 'svn lock' takes too long).
Thanks for the pointer,
Daniel
