RE: Merge Confusion
Sergei Organov wrote: > "Jim.Hyslop" <[EMAIL PROTECTED]> writes: > > You will have to use 'cvs add' and 'cvs remove' to have these files > > added or removed from the trunk. > > I don't think he will. At least for me it works > automatically. I mean all the files are already added/removed > after the merging command has been executed, so I only need > to commit (after resolving conflicts, if any). Good thing you and Larry are here to keep me honest ;-) Sorry about the misinformation, Rick. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge Confusion
Jim.Hyslop writes [re merging]: > > You will have to use 'cvs add' and 'cvs remove' to have these files added or > removed from the trunk. Not so -- a merge with two -j options should handle that automatically. -Larry Jones What a stupid world. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge Confusion
"Jim.Hyslop" <[EMAIL PROTECTED]> writes: > work wrote: [...] > > At this point, I'm not overly concerned about deleted or added files > > (to me they are much easier to deal with since the entire file is > > involved). > You will have to use 'cvs add' and 'cvs remove' to have these files added or > removed from the trunk. I don't think he will. At least for me it works automatically. I mean all the files are already added/removed after the merging command has been executed, so I only need to commit (after resolving conflicts, if any). -- Sergei. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge Confusion
"work" <[EMAIL PROTECTED]> writes: > Ok, Based on 2 emails from this list, the CVS manual, and the Essential CVS > book, I'm confused about the whole merge what tag where stuff. I hope I craft > this email to get a clear answer to unfog my head. Project Name: testproj > Local Sandbox is: rel_1/testproj while in local sandbox, issued cvs tag > rel_1-before-branch > > then issued cvs tag -r rel_1-before-branch -b rel_1 > then issued cvs tag rel_2_start Still in the rel_1/testproj sandbox I issue > the the cvs update -r rel_1 command. This now updates the rel_1/testproj > sandbox to contain the branch. I then backup a couple of directories and > create a new directory called rel_2 and issue the command cvs checkout > testproj (this then creates a local sandbox rel_2/testproj that contains the > trunk. Now, I make bug fixes to rel_1/testproj and want to merge these changes > into rel_2/testproj. The files in rel_1/testproj contain a mix of added, > modified, and deleted lines. At this point, I'm not overly concerned about > deleted or added files (to me they are much easier to deal with since the > entire file is involved). I go into the rel_1/testproj sandbox and issue the > following commands: make sure i have the latest sources - cvs -q up -dP > > tag the repository - cvs tag rel_1-20040630 I go into the rel_2/testproj > sandbox and issue the following commands: make sure i have the latest srouces > - cvs -q up -dP > > tag the repository - cvs tag rel_2-20040630 Now I'm ready to merge. Since I > want to merge from the branch into the trunk, I'll be in the rel_2/testproj > sandbox. Which command do I issue? Well, I didn't find a correct one in the list you've provided, so here is how I would do it: All you've made so far is OK, but I'd add one more tag that marks the last revision on the branch you've merged up to so far. For now, set it to the root of the branch as we didn't merge anything yet: $ cvs rtag -F rel_1-merge -r rel_1-before-branch testproj (maybe rel_1-last-merge is even better name for the tag) Then, the merge itself would be: 1. Tag current branch state with rel_1-tmp tag. $ cd ~/rel_1/testproj $ cvs update -d -P ... make sure you have no local changes ... $ cvs tag -F rel_1-tmp 2. Merge changes between rel_1-merge and rel_1-tmp into rel_2: $ cd ~/rel_2/testproj: $ cvs update -d -P ... make sure you have no local changes ... $ cvs update -d -P -j rel_1-merge -j rel_1-tmp 3. Resolve conflicts, commit changes back. 4. Move the rel_1-merge tag to the rel_1-tmp tag to record the point in the branch for the next merge: $ cvs rtag -F rel_1-merge -r rel_1-tmp testproj That's it. Rather simple in fact. Please note that all this business with rel_1-tmp tag is there to prevent troubles when some other developer commits something on the branch after you've invoked merge command but before you've moved the rel_1-merge tag. In your particular case, rel_1-tmp is the same as your rel_1-20040630, so you can substitute the former by the latter in the last two commands above. However, for me it seems easier to remember how to merge when involved tags are always called the same for given branch. This way every next merge of changes made on the rel_1 branch will look exactly the same. -- Sergei. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Merge Confusion
work wrote: [snip details] > while in local sandbox, issued cvs tag rel_1-before-branch > then issued cvs tag -r rel_1-before-branch -b rel_1 > then issued cvs tag rel_2_start [...] > I go into the rel_1/testproj sandbox and issue the following > commands: > > make sure i have the latest sources - cvs -q up -dP Excellent - people sometimes forget this important step > tag the repository - cvs tag rel_1-20040630 > I go into the rel_2/testproj sandbox and issue the following > commands: > tag the repository - cvs tag rel_2-20040630 > > Now I'm ready to merge. Since I want to merge from the > branch into the > trunk, I'll be in the rel_2/testproj sandbox. Which command > do I issue? Remember that, unless you are doing something extremely unusual, both tags in the update command should be on the same branch. This eliminates any of your options involving tags on the trunk, leaving only: > 3 - cvs up -j rel_1 -j rel_1-20040630 > 5 - cvs up -j rel_1-20040630 -j rel_1 > 7 - cvs up -j rel_1-20040630 'cvs update -jX -jY' says "take the delta from X to Y and apply it to the current directory". Now, because you applied the tag rel_1-20040630 to the tip of rel_1 branch, that means rel_1 and rel_1-20040630 refer to the same revision (unless somebody checks something into the branch while you're doing this, but we'll leave that aside for now). This means that 3 and 5 are no-ops: there is no difference to apply. This leaves option 7. In this particular case, it will work. With only one -j option specified, CVS will automatically determine the correct base point to use. CVS will act as if you had issued the command: cvs up -r rel_1-before-branch -j rel_1-20040630 As I said, *in this case* it will work. In subesequent merges, it will not work: you must explicitly specify the starting point, otherwise CVS will again use the common ancestor as the starting revision, and you'll get the same changes merged twice. Thats why I prefer to always use both -j options when merging. > At this point, I'm not overly > concerned about > deleted or added files (to me they are much easier to deal > with since the > entire file is involved). You will have to use 'cvs add' and 'cvs remove' to have these files added or removed from the trunk. > This looks something like a quiz, but I'm not the teacher, I'm just a > horribly confused student and really don't want to screw up > 10,000+ files > that are under cvs control. For these situations, you can always set up a test portion of the repository. Create a directory, say $CVSROOT/cvs-test, and try it out there. The understanding is that anything in cvs-test can be deleted without warning, and nothing of value should go in there. Also, remember that even if you mess up on some of the commands, nothing gets committed until you issue the "cvs commit" command. So, if worse comes to worst and you've really mucked it up, just blow away your working copy, check out a fresh copy and try again. Happy merging ;) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
