Malcolm Rowe <malcolm-svn-dev@farside.org.uk> writes:
>So the solution is pretty straightforward: just change the structure so
>that r0,r1,r10000,r10001 go into revs/0/0, revs/0/1, revs/1/10000,
>revs/1/10001, etc.
There are variations on this scheme, each with their relative merits.
I don't want to be involved in bike-shedding, but these are details to
consider when designing the directory layout:
- top-down (as in your example) vs bottom-up (where r70123 would be in
3/7012 or 23/701); this is mostly a question of locality versus
distribution
- make directories more compact by omitting duplicated digits
(putting r40123 in 4/123 instead of 4/40123)
- fixed number of directory levels from the beginning, or using an
auto-scaling scheme (ie, r1-99 at top level, r100-9999 using one dir level,
r10000-999999 using two, etc)
>But at the same time, I don't want to force this change upon anyone
>who does have a decent OS filesystem. The scheme above would almost
>certainly be less efficient on any tree-based filesystem, since we're
>adding another level to the hierarchy. Additionally, the correct maximum
>number of files will differ depending upon the filesystem.
I challenge you to find any difference in performance between a linear
and tree-based repository in practice.
The fewer decisions that have to be made at repository creation time
the better, in particular if wrong decisions will force the
administrator to rebuild the repository later when it has grown.
This is just a plea for sensible defaults that will give good performance
on all systems for all repositories.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 5 11:48:39 2007