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

FSFS locks questions and a concern

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 11 Nov 2010 23:25:40 +0200

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").
Received on 2010-11-11 22:28:44 CET

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