solo turn <soloturn99@yahoo.com> writes:
> can we make a new pre-1.0 issue for speeding up the client?
>
> contents:
> goal is to reduce the number of files and directories held in .svn,
> cause this does currently not scale and is unusable for checkouts to
> network drives.
>
> especially:
> - put prop-base, props, wcprops into entries file
> -3 files per managed file
> -3 folders per managed folder
> - put dir-wcprops in entries file
> -1 file per managed folder
> - put auth in ~/.subversion
> -1 folder per managed folder
> -2 files per managed folder
> - put empty-file, Readme
> in temporary location or root
> -2 files per managed folder
> - put format in entries file or root or temporary
> location
> -1 file per managed folder
> - eliminat "text-base" folder and store the
> contents directly in .svn
> -1 folder per managed folder
>
> this means in total:
> -5 folders per managed folder
> -5 files per managed folder
> -3 files per manged file
>
> root is the most top folder, where a .svn folder exists.
Are you sure that such a change is going to make things faster?
Some possible problems:
- It will mean that all the properties have to be read and parsed
every time the entries file is read, irrespective of whether they
are needed. That is likely to slow down the client, not make it
faster.
- Are you proposing that properties are cached in the access batons
along with the entries? Properties can be *big*, it's possible that
the memory use would be unacceptable.
- If you don't cache properties then it becomes necessary to parse the
entries file every time you access the properties. This will be
slower than simply parsing the current properties files.
- It will take longer to write the entries file each time it is
modified. I suspect that writing the entries file is a real
scalability problem, I think that it's one of the things that causes
Subversion to slow down when updating a directory with a large
number of entries. See notes/entries-caching for my (barely
developed) ideas for solving this.
- The entries file is XML, properties are binary. Will we need to
encode/decode properties?
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.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 5 15:37:50 2003