I'm not talking about checking out at all. Just svn status and svn update mainly. The speed problem I am having involves the local hard drive and not the repository connection at all. I am not at work yet but when I get there (in about an hour) I will get exact times and sizes for each operation.
We don't have source for our build tools - Visual Source Safe, Watcom, Intel compilers, etc. But those extra files could just as easily be source files and the local operations would probably be just as slow. My guess is that directory scans across the whole working copy and the pristine copy are what's slowing us down.
From: Bob Proulx
Date: 8/21/05 9:22 pm
To: Robert Cronk
Subj: Re: Subversion working copy speed
Robert Cronk wrote:
> Thanks for the speedy reply. We use Linux (ext3) and windows (NTFS) on the
> clients and Linux (ext3) on the server where the repository is
I have heard reports that NTFS is slower than ext3. But on my linux
filesystems (mostly reiserfs) I do not see anything that I would count
as a speed problem. A large-ish working copy (several hundred
megabytes) I can 'svn status' in less than 5 seconds. That same
working copy on HP-UX takes over two minutes. That prompted my reply
about filesystem speed.
> It would be nice if there was an index or something that could help
> it be faster on the client side. Our repository is in the
> Multi-Gigabyte range. We actually store our build tools in it too
> so that our builds are completely self contained. This is part of
> the reason for the large repository size.
Uhm... I think what you just told me is that you check in the
binaries for your build tools too. That is pretty extreme. I would
just check in the source for the build tools.
> It all works beautifully except for the speed. Sure, a faster hard drive
> and filesystem would help, but an index (or something) would be nice too
> and would benefit all platforms. I do like that there is a local pristine
> copy - especially when I'm working remotely from a 57.6 Kbps connection!
Exactly what operations are you referring to when you say fast or
slow? I probably jumped to conclusions with my statement about
filesystem speed because of personal experience. Because to me I
expect 'svn status' to be very fast. Along with all of the other
local operations such as 'svn diff' and things like that. Remote
operations will be limited by your connection and server speed.
But if you are checking out a multi-gigabyte working copy over a 57.6
kbps connection I think you have just answered for yourself already
why your operations are going to be very slow. Checking out a one
gigabyte working copy at 57.6kbps would take five hours just to copy
the data across the connection!
Can you report the times for some typical operations?
time svn status
time svn diff
time svn update
time svn update # time when the wc is already up to date
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Aug 22 16:02:59 2005