On Tue, Jul 20, 2004 at 06:31:09PM -0400, Garrett Rooney wrote:
> Mark Benedetto King wrote:
>
> >On Wed, Jul 21, 2004 at 12:05:47AM +0200, Sven Mueller wrote:
> >
> >>Anyway, what I really meant was: That person (you?) overlooked the
> >>pretty well known problems with huge directories. Making mistakes is
> >>human. However it is pretty difficult to change FSFS layout now without
> >>breaking existing installations.
> >
> >
> >Actually, here's a strawman plan:
> >
> >At open time: determine whether we have a new format or old format
> >repository (based on, perhaps, the content of "format", or the existence
> >of new-format-only directories). If old format, convert to new format.
> >The conversion be essentially a few mkdirs and bunch of rename operations.
> >This could even be written as a shell script.
>
> Why bother? Just have fallback code that tries to open the file as it
> would have existed in the previous naming scheme. If someone wants to
> convert they can dump/load.
Fallback code is tricky business (which is why the configurable
WC admin directories never got off the ground, IMO).
If we don't want to *require* a conversion, we could have an internal
vtable that provides path_rev() and path_revprops(), or we could
have those functions behave differently based on the repo format.
> >Instead of putting revision N in revs/N, put it in revs(N/1000)/N.
> >This gives us 1000 files per revs dir, and doesn't use more than 1000
> >revs dirs until after 1000000 revs. The same thing goes for revprops.
>
> I'd suggest revs/(N/1000)/N, so we don't clutter up the db directory.
>
The dirnames would clash with existing revs, but yes, I agree, we
shouldn't clutter the db directory.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 21 00:45:05 2004