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

RE: Speeding up workspace

From: Bert Huijben <rhuijben_at_sharpsvn.net>
Date: Fri, 13 Feb 2009 09:02:54 +0100

> -----Original Message-----
> From: Listman [mailto:listman_at_burble.net]
> Sent: vrijdag 13 februari 2009 3:36
> To: Bert Huijben
> Cc: users_at_subversion.tigris.org
> Subject: Re: Speeding up workspace
> On Feb 12, 2009, at 12:41 AM- Feb 12, 2009, Bert Huijben wrote:
> >> svn update is very slow with our (very large!) working copies since
> >> it
> >> needs to
> >> figure out whats changed before performing the update. this is
> >
> > Actually it doesn't have to do this... (and doesn't)...
> >
> > It just has to look if there are switched locations in your
> > workingcopy. If
> > something has changed (or not) is only interesting when changes are
> > merged
> > into your working copy.
> i thought that to determine whats changed in a working copy svn needs
> to do a sweep
> looking for changes.
> you're saying that svn doesn't do this?


(At least this is what I tried to say:)

Just to determine what it must update in a working copy it doesn't have
to look at what changed in that working copy.

It asks the repository: After locking the working copy (Slow) and
looking what you have checked out (Fast) it asks the repository 'What
changed since my last update' (Fast)..

Locking workingcopy: Reading entries file + writing .svn/lock file in
every directory (writing .svn/lock is slow on Windows and network)
Looking what is checked out: Reading entries file (cached)
Asking repository what changed: Proportional to what changed in the
repository, can be virtually 0 when the repository has no updates

As answer to what changed the repository answers with a so called
'editor drive' that describes the actual changes and only when these
changes touch something in your working copy it has to determine if
there are potential conflicts with your local changes. (Auto merging,
interactive merging, etc. is handled at this step)

So, to answer your question: For just 'svn update'ing it doesn't have to
check everything in your working copy for changes.

So my question to you was: Can you determine where your delay is?
* In this lock step (as I measured on Windows)
* Or in the actual update step.

In a GUI client you can see where the second step starts by looking at
the network traffic/progress. (The lock step doesn't access the network)

I was pretty shocked to find out that most time was spend on just
getting the working copy locked and not on doing something (at least a
bit) useful.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-13 14:10:46 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.