Re: Merging Question

[Eric Siegerman]

On Fri, Dec 22, 2000 at 10:13:08AM -0600, Alexander Kamilewicz wrote:
> However, the
> crux of my problem was that whenever I've been importing their new
> changes into a module, I _never_ get a conflict message.  This is
> important, because in most cases I _know_ a file has changed (usually
> index.htm).

No single change can result in a conflict.  In your example, the
distribution has changed, but you've made no local changes.
Similarly, if you had made a local change, but that particular
file was the same in the release-1 and release-2 distributions,
there wouldn't be a conflict.  A conflict only occurs when the
distribution and your local copy have *both* changed.

> Thus, I embarked on the following simple exercise to prove myself right
> or wrong:
> [Previous steps omitted, for now...]
> 7.  It imports fine with no conflicts.

And so it should, because there are no conflicts.  Thus, this
behaviour is also correct:

> 10.  I get "page1" with "second time" and "first time" is nowhere to be
> seen.


To create a conflict, modify this test procedure as follows:

> 1.  I create a directory called "acktest" with one file called "page1"
> that has one line that says "first time".  No quotes in any of this, of
> course.
> 
> 2.  I import this into CVS as such:  $cvs import acktest vendor release1

      (NB: You have the right idea for the third argument, but
      the second should be the same for all import's; hence no
      need for a number.  I've changed it to from "vendor1" to
      "vendor".)

>
> 3.  It imports fine.
>

  3.1 Check out a sandbox:
        cvs co -d acktest-sandbox acktest

      (NB: I call the sandbox "acktest-sandbox" here only to
      avoid collisions with the "acktest" directory, which you
      use for the third-party distributions.  In practice, I'd
      call the sandbox "acktest" and put the distribution
      directories elsewhere -- they're transient anyway.  Either
      way, I'd *certainly* avoid using the same directory for
      both purposes, with all the resulting deleting/recreating
      that you described.)

  3.2 Make a local change, and commit it:
        cd acktest-sandbox
        vi page1        # Make it say "first time, revised"
        cvs commit -m 'A local change to version "first time"'

  3.3 Tag the state of the world before doing the next import:
        cvs tag release1-preupdate

      (I talked recently about how to do a "paranoid"
      import/merge; now I get to talk about why :-)  I'll do that
      in a minute; for now, just humour me and make this tag.)

> 4.  I rm -rf acktest.
> 
> 5.  I repeat step #1 with the one change that the one and only line now
> says "second time".
> 
> 6.  I import this into CVS as such:  $cvs import acktest vendor release2

      (NB: "vendor2" changed to "vendor", as in step 2)

> 7-b It imports, but says there's a conflict.

  7.1 Merge the changes:
        cd acktest-sandbox
        cvs update -jrelease1 -jrelease2

  7.2 Resolve the conflict:
        cd acktest-sandbox
        vi page1        # We'll change it to "second time, plus first-time 
revisions"
        cvs commit -m 'Merge "first-time" revisions into "second-time" 
distribution'

  7.3 Tag the results:
        cvs tag release2-merged

      (NB: This is also part of the "paranoid merge".  It doesn't
      come into play in this message, and is shown only for
      completeness.)

> 
> 8.  I rm -rf acktest
> 
> 9.  I $cvs checkout acktest
> 
      (NB: There's no real need to do this in practice, since you still
      have acktest-sandbox.  But for the sake of argument, suppose you
      do it anyway.)

 10-b Now you get "second time, plus first-time revisions"


> [...] there appears to be a) no
> version history and b) no way of "rolling back" when it turns out that
> their new changes aren't up to snuff.

a) To convince yourself that there *is* version history, type:
        cd acktest-sandbox
        cvs log | more

b) To roll back to the first import, as received from the other
   group, do:
        cd acktest-sandbox
        cvs update -r release1

   But that loses your local patches to release1.  What you
   probably wanted was:
        cvs update -r release1-preupdate        # Roll back to release1, plus 
local patches

   This is why we did step 3.3.


<gripe>
> This message is intended only for the use of the addressee(s) named
> herein. [7 more lines deleted]

Do the lawyers who dream this crap up ever subscribe to mailing
lists?  (Alexander, I know this isn't your doing; my gripe isn't
directed at you personally.)
</gripe>

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Nobody ever got fired for buying Microsoft -- but they could get
fired for relying on Microsoft.
        - Chris Garrigues