On Tue, 7 Dec 2004 kfogel@collab.net wrote:
> Mark Benedetto King <mbk@lowlatency.com> writes:
> > > Of course, we could hash every single path prefix leading up to a
> > > given path, and store one file for each. That might work, but it's a
> > > lot of files, whether or not they're all in the same directory. If C
> > > is the average number of components in a repository path, then we'd
> > > need C*N physical files to lock N repository paths. Yuck.
> >
> > Only if they were all in completely different paths. I think that in
> > practice it would be closer to N*log(N).
And note that we have the same amount of directory entries today in the
tree structure.
>
> Oh! Good point -- I think you're right. (Peter's point about
> ref-counting does hurt, though.)
>
I'm not sure that a flat storage (possibly partitioned so we don't get too
many files per directory) is that bad. We will have to keep a write lock
while taking out a lock, so atomicity is no problem.
Prposal:
A lock is represented by a file whose name is the hash value of the
absolute pathname. The contents are like today: a hash of token, owner,
etc.
For each ancestory of the lock in the path hierarchy, a directory is
stored in a file named by the absolute pathname. That file contains a hash
(for extensibility if we want to support directory locks). ONe hash key is
ref-count.
When creating a lock:
Get write lock (commit lock)
Check if the lock already exists.
Create or increment ref count for each ancestor of the path to be locked.
Create the lock file.
If an error is encountered when incrementing a refcount or creating the
lock file, walk up the ancestor tre and try to unref each directory file
that we reffed earlier.
Release the write lock.
Note that we reference the directory files before creating the lock file.
This ensures that there will not be a lock file with missing directory
files if something unexpected happens. There could of course be stale
directory files lying around. That's not any worse than the implementation
with real directories.
When releasing a lock:
Get the write lock.
Remove the lock file.
Walk up the directory tree and unref each directory file. (Unref means
decrement ref count and remove file if the count drops to zero, as one
would expect.)
Release the write lock.
Getting an error during the unref step will leave stale references. That's
the same as failing to remove a directory in the current implementation.
What does all this buy us? As discussed earlier in this thread: avoids any
limitations of filesystem path lengths and avoids encoding escaping.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 7 17:13:38 2004