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

Re: [RFC] A libsvn_wc properties optimisation

From: solo turn <soloturn_at_gmail.com>
Date: 2004-11-08 15:13:59 CET


for a typical up (max 300 files changed) we experience 10 times slower
runtimes on windows as on linux, reiserfs. our wc contains ~100 000
files and 35 000 directories (including the .svn).

our biggest problems currently are:
- svn asking for username/pwd AFTER locking the whole wc
  which is after 2-3 minutes
  if it would ask immediately it would be great.
- the long runtime on windows in general for "up", "cleanup", "status"

so we'd appreciate anything which does something in this respect and
volontarily test anything.


On Sat, 06 Nov 2004 14:28:34 +0000, Philip Martin
<philip@codematters.co.uk> wrote:
> Barry Scott <barry@barrys-emacs.org> writes:
> > The win is that you only have to do a file open on one file rather
> > then lots of files/directory. I'm sure that parsing one file is far
> > faster then open 10 files. The file sizes are trivial. I have 1856
> > bytes for 54 files in my repo for example.
> The "I don't have any large properties, why should anyone else?"
> argument, that came up last time as well.
> Suppose one of the files has a 1MB property, now every operation that
> reads properties on any file now has to read that all that data.
> > I not sure what you are getting at with caching in memory. A command
> > like svn_client_proplist will open the file, read and parse and return
> > the info in an apr array alloc'ed in a pool. Where is the caching?
> Consider
> do_something(directory):
> foreach (item in directory)
> if (item is a file)
> do_stuff_that_uses_file_properties(item)
> else if (item is a directory)
> do_something(item)
> How often does do_stuff_that_uses_file_properties need to read that
> single properties file?
> What about checkouts? If you simply re-write all the properties seen
> so far as each file arrives then the total amount written goes up
> quadratically (appending to a file is difficult to do atomically). We
> had exactly that problem with the entries file.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 8 15:14:27 2004

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.