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

Re: svn commit: r12175 - branches/locking/subversion/libsvn_fs_fs

From: <kfogel_at_collab.net>
Date: 2004-12-07 00:32:49 CET

Garrett Rooney <rooneg@electricjellyfish.net> writes:
> I was thinking that if we're going to try to avoid problems with
> hitting invalid characters on the host system we might as well try and
> avoid going over the maximum path length as well. One way to do that
> would be to put all the locks into a single directory, using a hash of
> the entire path to name the files. If we're worried about the number
> of items in the directory we could just split into subdirectories
> based on the first few characters in the hash.

That doesn't work as easily as one would hope, because we need to look
up path prefixes too. (Peter Lundblad pointed this out to me when I
had the same thought.)

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.

> Of course the files would have to store their full path name
> internally, for sanity checking, and there would need to be some
> mechanism for avoiding collisions in the hash.

I'm not sure it'd even be worth checking for hash collisions. The
failure case is not life-threatening -- something gets reported as
locked that isn't, or a lock is ignored that shouldn't be, right?
We'd have to work out the exact consequences, but anyway collisions
are so unlikely that the extra code may not be worth it.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 7 00:38:24 2004

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.