[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: Kirby C. Bohling <kbohling_at_birddog.com>
Date: 2002-04-29 22:36:34 CEST


Karl Fogel wrote:
> "Kirby C. Bohling" <kbohling@birddog.com> writes:

I think you missed by big gripe. Sometimes internally CVS and
Subversion use diff/diff3/patch and I can't control the parameters to
it. So for update and update -j in CVS I didn't get to tell CVS what
parameters to use for the diff and patch. I could have fixed my
problems thru CVS if I had control, but I didn't. The cvs diff command
allowed exactly what I wanted to do with update and update -j.

>>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').

Okay, I forgot, with diff3 you get both files, so the context handling
should be better in svn then CVS. I haven't ever used diff3 by hand so
it might solve all my issues.

It is a diff problem, if the diff didn't give you the context, patch
couldn't use it. I'll go build test cases and try it out with diff3.

>> 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" ...

I know I get that, but for CVS, I didn't get that on a

cvs co module
cd module
cvs update -j branchHead

        Where exactly did I get to pass the diff/patch options for pattern matching?

Now I could do this:

cvs diff -r lastMerge -r branchHead "diffOptions" module > branch.patch
cvs co module
cd modules
patch "patchOptions" < branch.patch

        Now this looks like local edits to the trunk (which in CVS on a update -j
it always did). If the svn history takes off, that will make this even
harder to do and have svn keep accurate merge history. All because I
can't tweak out the parameters the way I want inside of the tool.

        I had no control over the parameters used for the merge ( I always
thought CVS used straight diff/patch possibly some rcs version of those,
I could be completely wrong. Everything I know about CVS I read out of
your book, so you're probably more knowledgable then I am :-).

        I have a ton of very similar code for 4 lines in a row, I would like the
ability to tweak out the diff/diff3/patch options to say 4 lines of
match isn't enough try 6-10, and hopefully say oh yeah skip whitespace
in there too. GNU diff's defaults aren't always ideal for all the code.
  I haven't looked at Sander's diff code so the options might not be there.

So for example if this worked, it be great:

svn update --diff3Options="use lots of context"
svn switch --diff3Options="use lots of context"

Or be able to say, look for at least 1-8K for matches, if that takes 10
minutes, I'll wait 10 minutes I just want it done correctly by the
computer that is good at the repetative work not by me the lazy bum.

Essentially anytime diff/diff3 is called, I like a chance to hint at how
to do the work. If I had to remember to do it each time, I can do that
too. 98% of the time the defaults are good enough. When I realize they
aren't, I'll start over and override the defaults. It's the 2% case
that is a real bear, and normally those are the cases will introduce
really subtle bugs in my code base because I missed something because
the conflict markers made it very hard to see the changes. It's why I
used cvs diff and patch by hand. IMNSHO, if I can get diff and patch to
do it handily an SCM should allow me to do inside of the SCM.

        Granted, this is the part where I should put my code written skills where
my mouth is and contribute the patch.

> 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".

Right new code, might be feature lite. No knobs just yet.

>>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/ :-)


I forget that isn't here just yet.

> -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 22:41:18 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.