You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nicklas Norling <ni...@ifsab.se> on 2004/05/07 11:48:39 UTC

'update' question

Hi.
 
I have a developer sitting on a pretty bad remote line with 500+ms network
delay.
 
He's getting the "updates" fast, but then it "just sits around doing nothing
for like
30 minutes". I asked him to clock it and he had to wait 30 minutes for an
update with
virtually no code coming out.
 
He's running the latest version of TSVN towards a subversion 1.0.2 server on
Linux
using the http access protocol. He's got a modern 7200 RPM HD.
 
I'm able to do exactly as him, but locally. The clock stopped at 38 seconds
with no code
checked out. My hardware are about the same as his.
 
However, when code are checked out, even locally, I have noticed that the
update "stops"
after the files have been transmitted. There appears to be high disk
activity for awhile until
it finishes. I'm seeing the same behavior with svn.exe.
 
What we're concerned with is that there might be some network activity
involved in this
"silent" period and that it's doing network "ping-pong" and hence might be
slowing
things down unnecessarily?
 
Can anyone enlighten us? Maybe this is already old news?
 
/Nicke

Re: 'update' question

Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-05-07 at 06:48, Nicklas Norling wrote:

> However, when code are checked out, even locally, I have noticed that
> the update "stops"
> after the files have been transmitted. There appears to be high disk
> activity for awhile until
> it finishes. I'm seeing the same behavior with svn.exe.

After all the files have been received from the server, there's no more
network activity.  The client has the tedious job of opening/saving
every single .svn/entries file in the entire working copy, in order to 
mark every file and directory as being at the HEAD revision.  That's the
disk-thrash you're hearing.

If you have a huge working copy (in terms of numbers of files and
directories), then this can take a while.  Rumor on the floor is that
win32 is at least twice as slow as *nix systems for this task...
something about win32 filesystem caching not being as fast as linux
and/or the win32 filesystem not being as efficient about dealing with
lots of small files.

>  
> What we're concerned with is that there might be some network activity
> involved in this
> "silent" period and that it's doing network "ping-pong" and hence
> might be slowing
> things down unnecessarily?

Nope, no network at all.  It's 100% disk i/o bound.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org