[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: Greg Stein <gstein_at_lyra.org>
Date: 2001-12-18 23:34:25 CET

On Tue, Dec 18, 2001 at 12:35:05AM +0000, Philip Martin wrote:
> Karl Fogel <kfogel@newton.ch.collab.net> writes:
>...
> > Philip?) Same strategy, I guess: just download both files and diff
> > them client side, the downloads can be diffs against the working copy
> > revision, and/or one of the downloads can be a diff against the other
> > download, whatever works best...
>
> I have been thinking about this, but it doesn't follow on quite so
> simply from the current code. The crawler used by diff is the same as
>...
> As you say there are two (at least) ways to approach this:
>...

How about a third:

* ask the server for differences between rev1 and rev2
* for each change, display that change

I'm not sure that we need working copies at all for this situation.

The query for the delta between rev1 and rev2 already occurs in a more
complex form for "svn update". We just dumb it down, add a new RA entry
point, and away we go.

We probably want to display a diff according to user prefs, which means that
we need both fulltexts on the client. Given that a WC might not even exist
(e.g. why should "svn diff -r 1 -r 2 http://svn.collab.net/repos/trunk"
require a WC?), then we need to fetch a complete file for rev1 and then an
svndiff for rev1->rev2, build a fulltext of rev2, then feed that to the
user's diff.

Note that a lot of this fetching behavior is also required by the merge
functionality. We should have a lot of the functionality now or RSN.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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.