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

Re: Unified context diff...(2) WAS: RE: svn commit: rev 1802 - trunk/subversion/libsvn_delta

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-04-29 21:10:54 CEST

"Kirby C. Bohling" <kbohling@birddog.com> writes:
> Uhhh, that is a feature, not a bug IMHO. One of the things I have to
> work around in CVS, is I can't tell it when merging I want you to use
> 8-10 lines of context. (Okay so now I will probably have 10 people
> tell me how I could have done it, which I would very very much
> appreciate if they did).

That's not a `diff' problem, it's `diff3' or `patch' problem.

And in fact, regular diff allows you to specify how many lines of
context it generates. The issue is getting patch to *use* that much
context (or, in our case, the issue is that Sander's replacement for
`diff3' is more important than the replacement for `diff').

> So maybe I should state that more directly. Would it be
> possible to have anything that does a diff be able to take parameters
> to pass to the diff utility/library? I would very much like to have
> finer control over the diff parameters on certain occasions rather

You have that right now:

   svn diff -x "options to diff go here" ...

Note: I'm not saying Sander's diff work isn't a good idea, just that
it's not giving us any functionality we don't already have. And until
it supports all the fancy diff options people use, like -b and -B and
-F, we'll unfortunately lose functionality by switching to it. And
replacing diff only affects with "svn diff".

For SVN, his replacement of "diff3" is what we should really be
testing, because:

   a) It's used more often (every update!)

   b) A bug would usually result in corrupted local files, rather than
      just wrong user-viewed output (they're both bad, but the first
      is worse)

   b) We know exactly which options we use; whereas with "svn diff"
      the user may want any of the zillion options supported by GNU
      diff, leaving us with the burden of reimplementing all of those
      if we internalize `diff' as well as `diff3'.

If we're going to test Sander's new code, test the diff3 stuff.
That's what we really need. The plain diff replacement has a lot
farther to go before it's useful.

> then doing svn/cvs diff followed by a manual patch. Especially
> because svn does a much better job of merge history then CVS ever did.

s/does/will do/ :-)

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 29 21:12:25 2002

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.