[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging Question
Re: Merging Question
Fri, 22 Dec 2000 13:39:29 -0500
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
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
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
> 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
> 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:
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:
cvs update -jrelease1 -jrelease2
7.2 Resolve the conflict:
vi page1 # We'll change it to "second time, plus first-time
cvs commit -m 'Merge "first-time" revisions into "second-time"
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
> 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:
cvs log | more
b) To roll back to the first import, as received from the other
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
This is why we did step 3.3.
> 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.)
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. address@hidden
| | /
Nobody ever got fired for buying Microsoft -- but they could get
fired for relying on Microsoft.
- Chris Garrigues