On Dec 6, 2004, at 5:43 PM, Garrett Rooney wrote:
> kfogel@collab.net wrote:
>
>> 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.
>
> Yeah, that does kind of suck...
>
> I suppose we could handle collisions by storing multiple lock tokens
> in each file, and that would allow us to use a single file to
> represent all the locks under a given prefix.
>
> Of course then removing a lock kind of sucks because we have to copy
> the file, removing a single lock from it, and copy it back over the
> original. Ick.
>
> Yeah, I'm not sure what the best way to go is.
>
Here's another possible strategy: store the whole "tree of locks" in
single file. It would essentially be 'transaction' file that never
goes away. That strategy is the very reason why FSFS hasn't had to
worry about UTF8 or path-length limitations of the host OS.
---------------------------------------------------------------------
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:54:31 2004