Merging question - from and to
Hi I have a question about merging. I thought merging with two -j options was 'from' revision and 'to' revision. This is what happened in my working area from trunk. I have a file soa.pc, branched out at 1.2, now at revision 1.2.4.1 on branch, and 1.2 on trunk. I check-out from trunk, then do cvs update -j 1.2.4.1 -j 1.2 soa.p Nothing happens. I then tried cvs update -j 1.2 -j 1.2.4.1 soa.pc RCS file: /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v retrieving revision 1.2 retrieving revision 1.2.4.1 Merging differences between 1.2 and 1.2.4.1 into soa.pc I also tried in another way, cvs update -j Br_CRMR2a_Dev soa.pc Nothing. Then cvs update -j HEAD soa.pc RCS file: /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v retrieving revision 1.2 retrieving revision 1.3 Merging differences between 1.2 and 1.3 into soa.pc I don't understand how this works? Is the order from-to or to-from or how are we supposed to give the -j options? Pls clarify. Thanks, Jeeva __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merging question - from and to
Jeeva Sarma [EMAIL PROTECTED] wrote: I have a file soa.pc, branched out at 1.2, now at revision 1.2.4.1 on branch, and 1.2 on trunk. I check-out from trunk, then do [ ... ] cvs update -j 1.2 -j 1.2.4.1 soa.pc Yes, like that. The command means, merge all changes that occurred between 1.2 and 1.2.4.1 into the working copy, which is what you want. What is confusing you is that there are *three* revisions involved: the base of the changes to merge, here 1.2, the endpoint of the changes to merge, here 1.2.4.1, and the working copy, which doesn't need to be called out by revision because it is the file sitting in your sandbox at the moment. In your case, the working copy is identical to the base, but this isn't always true. RCS file: /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v retrieving revision 1.2 retrieving revision 1.2.4.1 Merging differences between 1.2 and 1.2.4.1 into soa.pc After which the soa.pc in your sandbox should be identical to 1.2.4.1, but once again this was a special case because your starting point was identical to 1.2 . cvs update -j HEAD soa.pc RCS file: /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v retrieving revision 1.2 retrieving revision 1.3 Merging differences between 1.2 and 1.3 into soa.pc If you omit the first -j, it defaults to the most recent common ancestor of the given -j and of the working copy. Here HEAD means 1.3, because you or someone else committed changes after you checked out the sandbox with 1.2 . The common ancestor of 1.3 and 1.2 is 1.2 so once again you end up with a special case where the base and the working revision are identical. You are grabbing the changes from 1.2 to 1.3 and injecting them in 1.2, the result being identical to 1.3 . BTW, if you lose track you can always do rm soa.pc cvs update soa.pc to get a clean copy of the HEAD of the moment. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merging Question
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). Maybe I'm picking you up wrong in your description of the problem, but if you only ever import new versions of a file into a vendor branch, then I can't see how you would ever see a conflict. If a file changes external to your CVS repository between any two imports, then the latter import will result in a new revision of the file being created along the vendor branch, with another revision number.To use your example: The first time you import page1 into the vendor branch you will see: acktest/page1 ---1.1.1.1 in the repository. The second import of page1 will give you actest/page1---1.1.1.2 and so on. You can track what has changed in page1, between imports with: cvs diff -r1.1.1.1 -r1.1.1.2 page1 If on the other hand you modify page1 local to the repository, between imports, then when you commit your own changes, they will be committed on the trunk: actest/page1 1.1 If you then do another import of page1 after it has been modified externally, then you will need to merge your local changes 1.1.1.1 -- 1.1 and their external changes 1.1.1.1 -- 1.1.1.2 into the version on the trunk. You may or may not see a conflict depending on whether you and the other team both modified the same set of lines. Regards, Tony. -- == Tony Byrne [EMAIL PROTECTED], Swords, Co. Dublin, Ireland. MP3 Musician http://www.mp3.com/tony_byrne Get your copy of the Winamp MP3 player: http://www.winamp.com == ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merging Question
Aha! That makes considerably more sense than what I was trying to figure out on my own. Since changes generally haven't been made to the local repository copies, there have been no conflicts, but the Vendor history _is_ being kept. Thanks so much for your answer - I feel a lot better about how I'm going about this now. And nice music, by the way. Yours, Alex Tony Byrne 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). Maybe I'm picking you up wrong in your description of the problem, but if you only ever import new versions of a file into a vendor branch, then I can't see how you would ever see a conflict. If a file changes external to your CVS repository between any two imports, then the latter import will result in a new revision of the file being created along the vendor branch, with another revision number.To use your example: snip -- This message is intended only for the use of the addressee(s) named herein. The information contained in this message is confidential and may constitute proprietary or inside information. Unauthorized review, dissemination, distribution, copying or other use of this message, including all attachments, is strictly prohibited and may be unlawful. If you have received this message in error, please notify us immediately by return e-mail and destroy this message and all copies thereof, including all attachments. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merging Question
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.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merging Question
Alexander Kamilewicz writes: I've read all about Vendor branches in Karl Fogel's book and in the Cederqvist and thought I knew what I was getting in to. 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). You only get a conflict if two different people have modified the same line of a file; otherwise, CVS just quietly merges the changes. If you're just importing code and never making any local changes, you'll never see any conflicts. 8. I rm -rf acktest 9. I $cvs checkout acktest 10. I get "page1" with "second time" and "first time" is nowhere to be seen. That's to be expected -- you haven't specified any explicit version, so you get the most recent one on the default branch (which is the vendor branch in this case since you've never made any local changes; if you had made local changes, it would be the trunk instead). 11. And then, just to prove my fears, I go $cvs update -j vendor1 12. And it is still acktest/page1 with "second time" as the only line in the file. Of course. You've asked CVS to merge in the changes between vendor1 and vendor2, but you checked out vendor2 so they're already included and there's nothing to do. If you want to get the previous version, you need to use -r instead of -j. This worries me, of course, because while it's good that the new "sites" I'm receiving from Dev will now be in CVS, 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. Of course there's a version history -- do ``cvs log'' on a changed file and you'll see. -Larry Jones My brain is trying to kill me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
