hi,
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.
-solo.
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