On Fri, Oct 29, 2004 at 11:08:36AM -0400, Greg Hudson wrote:
> On Fri, 2004-10-29 at 10:49, Ben Collins-Sussman wrote:
> > I'm not worried about this. If we decide to implement locks in the
> > repos library, we can use "some random dbm"... whatever happens to be
> > picked up by APR. I believe that APR *always* picks up some system dbm
> > library. There's a whole apr_dbm_*() set of APIs, and mod_dav_svn
> > already uses them to manage a private table in repos/dav/.... even when
> > the repository itself is fsfs.
> "Some random dbm" won't work over NFS or another remote filesystem.
> mod_dav_svn does not keep its activity db inside the repository.
Even if it did work in the NFS case, we lose the robustness that is
one of FSFS's selling points.
> It's possible, and relatively straightforward, to make the locking table
> work using just the regular old filesystem. Just create a skeleton
> directory tree mirroring the part of the repository which has active
> locks. Store lock tokens at the leaves. URL-encode pathnames so that
> encoding issues don't come into play.
URL-encoding doesn't solve all the problems: what if the lock path length
exceeds the limitation of the local filesystem?
I think we can come up with a pure-FS based approach that doesn't require
a directory hierarchy isomorphic to the paths involved.
Just as an off-the-cuff strawman:
A "Lock Bundle" file has two sections:
/path/that/is/locked thelocktoken thelockuser otherlockmetadata
/other/path/that/is/locked theotherlocktoken theotherlockuser ...
There would be a well known "ROOT" lock bundle.
Note that /path/prefix3 points to the same bundle as /path/prefix1.
Ignoring the topic of physical file layout, this format would mean
that the lock subsystem could do the trivial thing (one bundle
per directory) or do something smarter to minimize the number
Additionally, if we allow duplicate (or overlapping) prefix
entries in the delegation table, that would allow us to impose
an upper bound on the size of the individual bundle files (which
would bound the work required to atomically rewrite them).
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Oct 29 18:34:45 2004