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

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.

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