Karl Fogel wrote:
> "Kirby C. Bohling" <email@example.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
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
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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Apr 29 22:41:18 2002