On Mon, 6 Dec 2004, Garrett Rooney wrote:
> kfogel@collab.net wrote:
> > "Peter N. Lundblad" <peter@famlundblad.se> writes:
> >
> > An escaping mechanism would be much more readable and debuggable. It
> > would preserve as much of the filename as possible.
> >
> > Of course, it has to be an escaping mechanism that escapes itself,
> > similar to "%" in C string formatting (though "%" itself may not be
> > the best choice for native filesystem portability).
>
> An escaping mechanism won't do anything to solve path length issues.
>
No, it will make it worse. But, as Karl points out, MD5-sums will often
lead to longer path components, so that might as well push us into the
PATH_MAX limit.
A solution would be to flatten the lockfile tree and store everything in
one directory. Then we would have to store quasi-locks for the
directories, since we need prefix lookup. This could be done using
ref-counting... This starts to smell too much complexity.
I think this is nasty, since we don't know if Karl's proposal will cause
problems in practice before users start to use it. But then we have to
live with it for compatibility...
I don't know today's shortest PATH_MAX that is in use today. (Windows has
255 or something, but that can be worked around.)
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 6 21:52:26 2004