Non-recursive "svn ls" is slow on wc path

[Tor Ringstad <to...@tandberg.net>]

I've noticed that a non-recursive "svn ls" is remarkably slower on a
wc path than on the corresponding repository url.

I checked the network traffic with ethereal for each case, and saw
some surprising differences. For my particular test case, an ls on the
wc path resulted in ~75KB of data being returned, and most of it
seemed to be about relevant objects. An ls on the url, however,
returned ~10MB of data, and apparently included log info for each and
every revision in the repository.

After looking around a bit, I found a comment in issue #1846 that
seemed relevant:

  Many commands that use svn_client__repos_locations will, when issued
  against a WC path, fetch the complete log of that path from revision
  1 to HEAD.

That issue was fixed on maintrunk in r9965/r10047. As far as I am able
to tell, it should then be included in 1.1.x (which branched later)
but not in 1.0.x (which branched earlier). I don't find any notes
about it being merged to 1.0.x later on.

I'm running 1.0.6 servers, and 1.1.0-rc1 clients.

That is, if the fix was client-side, I should have it already (and my
problem is probably a genuine new one). On the other hand, if it was
server-side, I don't yet have it, and upgrading might fix my problem.

Correct? What do you think?


- Tor Ringstad -




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

Re: Non-recursive "svn ls" is slow on wc path

[Ben Collins-Sussman <su...@collab.net>]

On Fri, 2004-08-06 at 10:57, Tor Ringstad wrote:

> That is, if the fix was client-side, I should have it already (and my
> problem is probably a genuine new one). On the other hand, if it was
> server-side, I don't yet have it, and upgrading might fix my problem.

In svn 1.1.x, in general, if you run 'svn subcommand wcpath', then the
1.1 client is going to try and and 'trace history' on the wcpath to
locate the correct object.  

In other words, it's the same as if you had typed 'svn subcommand -rREV
wcpath' (in this case, REV == some HEAD).  The client is "pegging" the
wcpath@BASE object, tracing back through that peg-object's history to
revision REV, and then running the command on the "older" object.  The
object might be the same, or it might be in a different location back in
REV.  That's the whole 'tracing history' aspect of svn 1.1.

The problem is, if the svn 1.1 client is talking to a 1.0 server, this
history-tracing algorithm can only be done by fetching every log of
wcpath@BASE.  That's slow.  If talking to a 1.1 server, the repository
instantly returns the path of the older object in REV, so it's quick.

So, in short answer to your question:  upgrade your server to 1.1, and
things will be normal speed again.



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