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

Re: "svn diff" performance

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-07-24 18:02:44 CEST

Marcus Comstedt <marcus@mc.pp.se> writes:

> Ben Collins-Sussman <sussman@collab.net> writes:
> > Vladmir,
> >
> > You're asking the server to compare two trees, namely '/' and '/'. Do
> > you have any idea how *big* those trees are? We have the /trunk tree,
> > and at least 4 copies of it in /branches, and 2 more copies of it in
> > /tags. And each source tree is itself pretty large, over 800 files
> > and directories to compare.
> Um, that sounds wrong. Why would it start comparing files in
> /branches and /tags? Shouldn't they have the same node id in both
> revisions, thus eliminating the need for further comparison? The same
> for any subdirectory in trunk which doesn't contain modified files.

Hm, yeah, you're right. As soon as svn_repos_dir_delta() sees that
the nodes are identical, it won't recurse. I take back my stupid
analysis. :-)

I think I have a better explanation of the problem now: it's that
stupid <resource-walk> tree being appended to the normal update
response. Generating that <resource-walk> tree means returning the
vsn-rsc-url for *every* item in the tree! *That's* probably why the
server is taking anywhere from 20 seconds to a minute to chug.

The underlying problem: 'svn diff -rX:Y' and 'svn merge -rX:Y' are
calling RA->do_switch() under the hood, which is a variant of
RA->do_update(). Because it's a switch, the <resource-walk> is being
sent. The design problem here is that only 'svn switch' actually
wants the resource walk. 'svn diff' and 'svn merge' don't care one

We need a way to prevent that resource walk from happening for two of
the three callers to RA->do_switch().

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 24 18:04:34 2002

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

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