[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-02-05 15:36:59 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.