All,
I am about to convert a fairly large CVS repository over to
svn (yay - thats hwta SVN aims at eh?). I'm going to be using
FSFS. I have been doing some tests, and I think I recall the
doc even talking about this, but as I understand it, each new
revision lands in a new file in revs/. Ofbviously, with
hundreds, thousands or even hundreds of thousands of revs,
this doesn't scale well on many platforms where you start
paying a severe penalty when a single directory has too many
inodes in it.
Did the designers consider a scheme similar to what Squid
does (it has the same problem, wants to put thousands of
cached files into a database)? An effective way to do this
is thus. Convert the revision number to a 8-digit hex number.
Take the very last digit as a top level directory. Take the
next two digits as a second tier directory. The create the
file inside that directory. This spreads the load out fairly
evenly, and I would image it would be pretty trivial to
imnplement.
If anyone likes the idea and can point me in the approximate
direction of the right place in teh code, I will work on a
patch to do so. However, fi this idea has been previously
suggested and subsequently rejected for some reason, I'd
be curious why it was rejected.
Kean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 7 09:13:35 2005