I see the script has a few obvious errors. I've snipped the offending lines from the quote below. I snagged the script from my shell history, but didn't clean it up quite enough.
> > cd /home/kbulgrien/tmp > > mkdir repository sandbox6 > > cvs -d /home/kbulgrien/tmp/repository init > > cd sandbox6 > > cvs -d /home/kbulgrien/tmp/repository co . > > echo "this is version 6" >source.txt > > cvs add source.txt > > cvs commit -m "v6 example" source.txt > > echo "v6.3" >source.txt > > cvs commit -m "v6.3" source.txt > > cvs tag v6_3 > > cvs tag v7_0_BEGIN > > cvs tag -b v7_0_DEVEL > > cd /home/kbulgrien/tmp > > mkdir sandbox7 > > cd sandbox7 > > cvs -d /home/kbulgrien/tmp/repository co -r v7_0_DEVEL . > > echo "this is the first v7 change" >source.txt > > cvs commit -m "add v7 feature" <snip> > > cd /home/kbulgrien/tmp/sandbox7 > > cvs diff -r v6_3 > > > See what I mean. Not so simple. <g> > > Seriously, it all does seems simple. But there seems to be many > things to watch for. I explored and it was just too confusing where > you will need helper batch files or frontends to do things like above. > No way I would of figured out the above. Nonetheless, I appreciate > the example. I am saving it so I can study it line by line. > > > Keeping up with the two sources is now quite easy. > > > > I won't go into merging. You could either use built in merge > > facilities of CVS, or you could even just use the differences > > and manually merge things. > > This is what I was somewhat referring to - merging related issues. > IMO, a very confusing aspect of CVS. I'd venture to say its not CVS, but revision control in general. You would face exactly the same issues in whatever revision control tool you decided to use. > >> Which leads me to my 2nd question: > >> > >> 2) Is there a "enhanced" version of CVS that allows for > two different > >> "trunks" per se? > > > > The branch checkout acts as its own "trunk" per se. I have > a hard time > > visualizing what you think a dual trunk would look like. > As far as SVN > > or other version controls systems go... I would think it > quite obvious > > that it would be a lot more difficult / time consuming to completely > > change your version control system than to learn how to use > branching, > > even if switching over appeared/was trivial. > > Right, I agree, which is why I have not made the jump to SVN or CVSNT > for that matter. I have to understand the problem first. :-) > > I have no idea what "trunk" means, so I extrapolating from my readings > and I really don't see a definitive answer. The common thing I see is > that it appears CVS only supports 1 trunk while others have supported > this idea in some better way. Look at the graphic here: http://www.akhphd.au.dk/~bertho/cvsgraph/#example The trunk is all the main line development with file revisions in the form 1.x. See how it kind of looks tree-ish (albeit the picture shows only branches on one side of the tree? The various branches all branch off of the trunk or other branches. > I'm not all sure what that means, but based on CVS readings, all > branches are temporary with the eventual idea that they will be merged > into a single trunk. That was still confusing, as I see some > "indications" that a BRANCH can begin a new "product version" that > will never be merged into some older "trunk" but a new "branch trunk" > per se. > > So as you see, it sounds simple, but I am probably wrong and I'm > confused <g> > > Overall, I was thinking ideally of having a single repository where I > can "STAMP" it v6.3 and begin a new "V7.0" and from that point on, a > new 5-10 years development cycle begins with 2-3 developers. But the > v6.3 version would still have a life for maintenance and any changes > made to it would not conflict with v7.0, however, the possibility is > known that there might be a Common Hot Fix to v7.0 that applies to > v6.3 as well. There are at least two main philosophies about branching out there... Some feel that trunk should always be used for current development, while others feel that new development should be done on branches so that there is a natural review when new development is merged to a stable trunk. The example I showed you put new 7.x development on a branch. I am not implying that is what you should do, its just what came to mind first. We could have just as easily tagged trunk with a 7.x tag, and at what ever juncture we needed to patch 6.x, made a branch there. That might be more what you had in mind. Here is one alternative sequence that keeps 7.x on trunk. cd /home/kbulgrien/tmp mkdir repository current cvs -d /home/kbulgrien/tmp/repository init cd current cvs -d /home/kbulgrien/tmp/repository co . echo "this is version 6" >source.txt cvs add source.txt cvs commit -m "v6 example" source.txt echo "v6.3" >>source.txt cvs commit -m "v6.3" source.txt cvs tag v6_3 cvs tag v7_0_BEGIN echo "this is the first v7 change" >>source.txt cvs commit -m "add v7 feature" Some time later we want to patch 6.3, so at that time we do this: cd /home/kbulgrien/tmp mkdir patched6_3 cd patched6_3 cvs -d /home/kbulgrien/tmp/repository co -r v6_3 . cvs tag -b v6_3_BRANCH cvs update -r v6_3_BRANCH echo "first 6.3 patch" >>source.txt cvs commit -m "6.3 patch 1" source.txt cvs tag v6_3_p1 Your sandboxes are now: . |-- current | `-- CVSROOT `-- patched6_3 `-- CVSROOT You can still compare stuff back and forth. Here is a scenario where we decide we want the patches in 7.x cd /home/kbulgrien/tmp/patched6_3 echo "v6.3 patch 2" >>source.txt cvs commit -m "Second v6.3 patch" source.txt cvs tag v6_3_p2 Ok, merge all the patches in source.txt back into 7.x: cd /home/kbulgrien/tmp/current cvs update -j v6_3_p2 source.txt Now our v7.x file looks like this: this is version 6 v6.3 <<<<<<< source.txt this is the first v7 change ======= first 6.3 patch v6.3 patch 2 >>>>>>> 1.2.2.2 CVS merged the stuff together, but we need to decide what to keep and what not to keep... The fixup might be as simple as removing the conflict markers or, it could be we need to manually integrate the changes based on what we know about the code. In this case, I'll edit the file this way. this is version 6 v6.3 this is the first v7 change first 6.3 patch v6.3 patch 2 I sometimes find the CVS merge hard to remember how to use since I don't use it often. In this case, using a common repository is still a boon. This time lets make a few changes on 7.x and then backport one of them down to 6.x cd /home/kbulgrien/tmp/current <Edit the file to look like this> this is version 6 v6.3 this is the first v7 change first 6.3 patch This is the second v7 change v6.3 patch 2 Commit it. cd /home/kbulgrien/tmp/current cvs commit -m "second v7 change" source.txt cvs tag v7_1 Edit again. this is version 6 This is the third v7 change v6.3 this is the first v7 change first 6.3 patch This is the second v7 change v6.3 patch 2 Commit it. cd /home/kbulgrien/tmp/current cvs commit -m "second v7 change" source.txt cvs tag v7_2 Later, we decide we want the v7_2 changes to source.txt in v6_3_p3. You can use CVS sort of like we did before, or you can use patching tools like patch, etc., or a graphical merge tool to compare the two projects an merge changes. I'll use *nix patch because is is easier to show in text. Method 1: cd /home/kbulgrien/tmp/patched6_3 cvs rdiff -u -r v7_1 -r v7_2 >patchfile Now patchfile contains: Index: ./source.txt diff -u ./source.txt:1.4 ./source.txt:1.5 --- ./source.txt:1.4 Wed Oct 29 13:48:54 2008 +++ ./source.txt Wed Oct 29 13:51:18 2008 @@ -1,4 +1,5 @@ this is version 6 +this is the third v7 change v6.3 this is the first v7 change first 6.3 patch This is easily to merge into our v6.3x source.txt file. I'll use *nix and leave Windows conversion as an exercise to the reader. patch isn't very Windowsy. In practicality I'd use WinMerge or a similar tool instead. cd /home/kbulgrien/tmp/patched6_3 patch source.txt patchfile rm -f patchfile Now, our source.txt on the 6.3 branch looks like: this is version 6 this is the third v7 change v6.3 first 6.3 patch v6.3 patch 2 We could have just as easily have done it the CVS way. First, we'll blow away the changes we made with patch (since we didn't commit them above. cd /home/kbulgrien/tmp/patched6_3 rm -f source.txt cvs update Now, re-apply the v7_2 change using only a CVS command: Method 2: cd /home/kbulgrien/tmp/patched6_3 cvs update -j v7_1 -j v7_2 source.txt The results are the same, but we didn't have to muck around with a third party tool: this is version 6 this is the third v7 change v6.3 first 6.3 patch v6.3 patch 2 > So after exploring all that by keeping/working with a test CVSROOT\WC6 > copy, I guess I didn't know all the CVS commands to do this, like > your batch file. > > So I ended up (and I do feel more comfortable this way), making a copy > of CVSROOT\WC6 to CVSROOT\WC7 and having two separare checkout > concepts and deal with any duplicate work, which in reality will > probably be less and less an issue as time goes on. Seriously, this is easy. We are talking less than ten commands, and they are all given. It is far more awkward to develop with separate repositories if you want to keep changes synced between the two. So... if you're maintaining two separate repositories... and still think it is "too hard" to change, why would you ask on the list for another way? At some point asking the question but not wanting to take time to learn is wasting somebody's time, eh? We all have jobs too. If you figure this out, it will help you for all time... 8.x, 9.x ... Pay now, reap benefits continually. By the way, before I wrote this, I didn't have experience using update -j as I have rarely had to merge. I just knew it existed. The point? I took time to learn to answer your question. Your turn... :-) --- Kevin R. Bulgrien Design and Development Engineer This email message is for the sole use of the intended recipient(s) and may contain General Dynamics SATCOM Technologies confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message.
