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

Re: `svn diff' progress

From: Colin Putney <cputney_at_whistler.com>
Date: 2001-12-20 18:29:02 CET

On Thursday, December 20, 2001, at 08:36 AM, Karl Fogel wrote:

> Colin et al,
>
> The sense in which cases (2) and (3) below involve the working copy is
> only this: that knowing the client-side revisions of various files can
> result in a more efficient (smaller) download from the server, because
> the server can send *both* files to be diffed as svndiffs against
> whatever's in the working copy.
>
> Completely agree that the working copy is not formally relevant,
> except as a provider of metadata and svndiff bases.
>
> Anyway, this so-called "efficiency" may or may not be worth the
> overhead; after all, in the case of two arbitrary revisions, there is
> some effort to be spent merely in determining whether or not sending
> the fulltexts would be more efficient anyway. :-)

Not so! Your comment above is true for case 2, in which a URL is diffed
against a URL - a working copy isn't even required for this operation.
But case 3 is different - let me give a more detailed example.

Imagine that I have a simple probject with experimental branch of
development. So my repository is laid out like this.

%find . -t file
./trunk/foo.c
./trunk/bardir/bar.c
./trunk/bardir/baz.c
./branches/experimental/foo.c
./branches/experimental/bardir/bar.c
./branches/experimental/bardir/baz.c

Now I do this:

svn co http:/host/repos/branches/experimental

svn diff -r 600:700 .

Clearly this cannot occur without a working copy. The client will have
to crawl the working copy to figure out the urls of the files it needs
to fetch and diff.

Colin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:53 2006

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.