Re: faster client pre-1.0: decrease number of files&folders in .svn

solo turn <soloturn99@yahoo.com> writes:

> --- Philip Martin <philip@codematters.co.uk> wrote:
> >
> > I can see there might be a benefit in combining some of the files
> > used to store properties, but I don't think putting properties in the
> > entries file is a good idea. Even combining them into a separate
> > file is not necessarily a win, it is likely to cause the same
> > scalability problems that affect the entries file. Such problems may
> > be solveable for the properties just as for the entries, but simply
> > assuming that it will be solved is foolish.
>
> from a typical use case, properties are not big, they are empty.
> therefor your concerns are theoretically ok, but in practice not
> (yet?) relevant.

Your argument appears to be "I don't do it, so nobody else should
either". There only needs to be one large property value on one file
in a directory for there to be a real problem.

> and we noticed slow down just by the number of files. we noticed slow
> down in disk usage, not memory usage, not processor usage.

"Slow down"? To what are you comparing it?

Obviously a large working copy is slower than a small working copy,
there's simply more data. We currently have a scalability problem for
directories with a large number of entries, but putting everything in
one file could well make that worse, not better.

> doing an svn up on 20.000 files/folders just blocks the disk for 2
> minutes.

"svn up" has to read every entries file, and you want to make the
files larger. How does that help?

> just deleting a svn working copy blocks the disk cause of the huge
> number of files.
>
> and the number is increasing by factor 10 (--> 20.000 files/folders,
> 200.000 files/folders with the .svn folders).

Do you have any evidence that it will be faster to use fewer, larger,
files? I can see that deleting a working copy might be faster, but is
it that really a more important use case than other svn operations?

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org