Re: Strategy to merge an Rev A.a modification into Rev A, B, C ... sources

[Eric Siegerman]

On Wed, Sep 04, 2002 at 09:32:57AM -0400, Jeff Kowalczyk wrote:
> Thanks, that makes sense.

Cool.

> since I have many one-line changes in
> each cgi script (e.g. I got rid of all the <font> tagging and bgcolor
> attributes)

:-)

> will merging the vanilla releases into my source require a
> manual review of every line differing from the new vanilla, every time? The
> vendor's B,C and future releases are generally fine-tuning, bugfix kinds of
> changes, and I need to make sure I don't miss any.

CVS tends to get this stuff right automatically, and to tell you
(by declaring a conflict) when it can't.  It isn't perfect,
though; it can occasionally make a real mess.  For what you
describe, though, it'll probably be ok.

Here's a trick I use for checking a CVS merge (or my own, when I
have to manually resolve a thorny conflict).  What one wants to
do is compare the output of two "diff" runs:
  - old vanilla vs. new vanilla
  - your old modified version vs. new modified version
to see that the same changes were made in both places; or, if
not, that you agree with any discrepancies.  This way works too:
  - old vanilla vs. old modified
  - new vanilla vs. new modified
I typically do it both ways; I think of it as "parallelogram
diffing", from vector geometry:


                 B' new modified
                 ^^
                / |
               /  |
  new vanilla B   A' old modified
              ^  ^
              | /
              |/
  old vanilla A

One of them is A-A' vs. B-B'; the other is A-B vs. A'-B'.

Of course, diffing "diff" output makes for an unreadable mess, so
instead I run both diffs in two xterm windows with the same
geometry, then flip back and forth between the windows a few
times quickly, looking for the characters that flicker.  Our
visual systems are very good at spotting movement :-)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
[...] despite reports to the contrary, it is the rare programmer who
permanently loses his sanity while coding ("permanently" being the
operative word).
        - Eric E. Allen