Re: CVS Update Behaviour

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Sunday, February 24, 2002 at 20:13:51 (-0800), Noel Yap wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> --- "Greg A. Woods" <address@hidden> wrote:
>> > "patch" has been a "standard" tool in unix development for nearly two
>> > decades now.  Prior to that the commonly used tool that can do the exact
>> > same job with only slightly less success and using the exact same tool
>> > to create the diff, was called 'ed'.  It's been around for over three
>> > decades now.  Time to crawl out from under your rock and get with the
>> > program Paul!
>> 
>> Greg, your experience is not the norm.  Most
>> developers, possibly sadly, aren't familiar with the
>> whole gamut of available commands.

>Any so-called developer who is not familiar enough with the tools used
>daily to do his or her job is not really a developer.  Some idiot might
>pay such a person to be a developer, but that doesn't make them a
>developer in the real world -- only in the imaginations of the employer
>and the employee.

Someone not familiar enough with the tools used daily to do his or her
job, etc. etc.  I think the point that Noel and I are trying to make is
that tools like "patch" are not used daily by the developers to get their
jobs done.  It just isn't needed and remain unknown for that reason.

>The tools I refer to are very plainly documented in the CVS manual and
>the CVS unix-style manual page.  Even a simple skim through the manual
>page for GNU diff (the diff used with CVS, though unfortunately it's not
>shipped with CVS) will also reference the manual page for 'ed' and
>'patch', and gives quite strong hints at how to use these tools to
>mechanically re-apply changes with them.  Anyone claiming to be a
>developer but not able to figure this out on their own really needs to
>be smacked with something a lot harder than a clue-by-4!

Why bother with "patch" when "merge" is better?  Or even better yet,
"cvs update"?

>> Furthermore, to do a proper merge, one needs three
>> files.  I think patch is incomplete since all the
>> information between the ancestor revision and the
>> current file is completely lost.

>You're on strange drugs again my friend.  The patch input file will only
>be incomplete if you fail to generate it properly.

>>  One of the first
>> lines in the output of "man patch" hints at this: 
>> 
>>     patch - apply a diff file to an original

>Uh hug.  Diff and diff3 produce "diff files".  Patch takes the output of
>diff _or_ diff3 as input.

Interesting, I just read the man page for patch again, and it
doesn't mention diff3.  According to this, all that "patch" does
is it takes the difference between one file and another, applies
the difference to a copy of the first file to produce a copy of
the second file.

This is a simple 2-way merge, which we all know is inferior to
3-way merges because they don't account for situations in which
the delta is applied to something that isn't identical to the first
file.

>> Since, when merging, one doesn't apply a diff file to
>> _the original_, patch isn't really the ideal tool to
>> do it.

>Well, first off, it seems you've got to learn a wee bit more about how
>'diff' and 'patch' work conceptually before you'll realise that "to an
>original" does not mean what you think it means.  Every newbie may
>suffer the same mis-interpretation, but I'm not sure that means the
>phrase is wrong in the context it is in.

After reading the man page again, I believe that "original" means a
file that is bit-for-bit identical to one of the files involved in
creating the difference that is fed to the the patch program.  However,
if the difference is presented in the context of surrounding lines,
then the patch program can be instructed to fudge a little on the
context.  But my experience with it does not indicate that it fudges
at all with the actual delta, but rather creates a second file
containing the changes it could not apply due to conflicts.  It
also refuses to apply a difference if it has to fudge too much.

I personally find diff3's mark-ups to be easier to work with than a
bunch of .rej files.

>--- End of forwarded message from address@hidden