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

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

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-09-06 03:41:56 CEST

On Wed, Sep 05, 2001 at 09:27:18AM -0400, Greg Hudson wrote:
> > Oh, screw that. Big time. The server should never have to fork like
> > that. The only thing missing here is context within our
> > svndiff. Once we have that, then an svndiff can be transformed into
> > a context diff or a unified diff.
> Oof. I don't think it's terribly easy to add context to a block-copy
> diff format. Maybe Branko has ideas on this. But I thought svndiff
> was only going to be used in cases where we expect to have the entire,
> unmodified diff source to work with.

Sure, but I was essentially proposing an optional extension to svndiff for
the purpose of getting context. Not that we'd always be inserting context!

> I think you're a little confused about the "custom diff program"
> feature people are talking about.

Nope. I was responding to Ben saying that we would fork "diff" on the server
to do a diff of, say, revisions 5 and 7. The server can do that inline,
today, but it would only return svndiff -- no context. So I suggested adding
context for that capability.

However... I think the answer of getting revs 5 and 7 down to the client and
using diff on that side is a bit better. That allows the client side to
select the context/unidiff format and other optional parms (e.g. how many
lines of diff context).

User-pluggable diffs on the client, only for output seems fine. The scary
thing is that, as I understand it, part of the "user pluggable diff" concept
is to plug in better diff algorithms, nominally for optimizing what we send
over the wire to the server. Ewww.


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.