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

Re: [SVN-DEV] Re: [Issue 422] Changed - "svn diff" needs to be fleshed out.

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-09-05 13:41:51 CEST

On Tue, Sep 04, 2001 at 03:49:08PM -0400, C. Scott Ananian wrote:
> On 4 Sep 2001, Ben Collins-Sussman wrote:
>
> > 1. svn diff foo.c
> > 2. svn diff -r 5 -r 7 foo.c
> > 3. svn diff -r 5 foo.c
>
> So, are you saying that if the user has a (client-side) custom diff
> program installed, that case 1 will behave (possibly radically)
> differently from 2 and 3?

Fitz needs to close his trap :-)

The whole "custom diff" thing is a lot of hand-waving and unnecessary
complication again. Just like that renamable .svn subdir "feature". For
starters, how are we supposed to deal with that custom diff's output? It
would probably need to produce the svndiff format; if it does, then it
probably means we wrote it; if so, then why is it "custom" rather than just
part of SVN?

Pluggable diffs and all the nastiness that comes with that is definitely a
post 1.0 item. IMO, just say no. :-)

> This seems like a misfeature. Why not check out the revisions into
> temporary files and then run the client-side diff? Slightly more
> inefficient, perhaps, but cooperates much better with the user's
> preferences. (The 'efficient' way to do this is to generate *svn* diffs
> between revisions, apply them to the working copy to create a pair of
> temporary files, and *then* run the user's 'diff' program on the pair.
> This way you get the efficiency of the server-side approach (since the
> server "knows" the diffs) with the consistency of the client-side model.)

For case 2: an svndiff with context from the server; no files transmitted.

For case 3: one file transmitted.

Note in all cases, we will eventually be using compression on those
transfers. Sending a file can still be expensive, but we can at least reduce
that expense :-)

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:40 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.