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

Re: Slow SVN Updates (though they shouldn't be).

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: Thu, 7 Feb 2008 15:33:08 -0600

On Feb 6, 2008, at 22:19, Gino Filicetti wrote:

> Hey guys, I was wondering if anyone could explain some annoying
> behaviour we've always seen whilst doing root level SVN updates in
> our (rather large) working copy.
>
> Problem....
>
> Run svn update on the root of our working copy, and the system will
> download the newly updated files from the server and then it will
> sit there and churn through at almost 100% cpu and with the hard
> drive reading and writing like mad. Sometimes it will do this for
> longer than it took to download the new files and eventually will
> return with the "At Revision xxxx" message and all activity ceases.

I would say that's not entirely uncommon. Though the 100% CPU
surprises me a little. I think it should be waiting on the disk here,
not the CPU.

> What exactly is it doing? Is it touching EVERY file in .svn in all
> subdirectories? I'm curious if there's anything we can do to
> improve performance or if we're stuck (and no, shrinking the size
> of our working copy is not an option).

It's not touching every file, but it is doing clean-up in the working
copy. And it needs to do something in each .svn directory.

> System Info....
>
> Windows XP
> SVN: v1.4.5
> Problem is the same whether using TortoiseSVN or using svn in cygwin.
>
> Working copy info....
>
> It's pretty big, using find and wc, I've calculated it out:
>
> -- number of files
>
> gfilicet_at_clc-gfilcet7-xp /cygdrive/c/chordiant/fnd62-rad7/workspace
> $ find . -type f -print | wc -l
>
> 72216
>
>
> -- number of directories
>
> gfilicet_at_clc-gfilcet7-xp /cygdrive/c/chordiant/fnd62-rad7/workspace
> $ find . -type d -print | wc -l
>
> 37773
>
> I realize this is also counting all the files and subdirectories
> in .svn, so these numbers should be halved (roughly).
>
> Any help is appreciated. It would be great if there were something
> we could do about this.

The time it takes is probably proportional to the number of
directories in the working copy, and 37773 is a largish number of
directories, so it will take some time. To make it faster, increase
the performance of your disk, like by getting a disk that spins at a
faster rate, or by setting up a larger disk cache is possible, or by
putting the working copy on a RAM disk or something.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-07 22:33:51 CET

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

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