[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: FSFS locks questions and a concern

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 13 Nov 2010 14:03:28 +0200

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,

Received on 2010-11-13 13:06:35 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.