Re: [boost] [release] Bad merge?
Rene Rivera wrote:
Something strange is going on, or went on, recently with CVS. The Jamfile.v2 on the RC_1_34_0 branch is no longer in a branch, and has the wrong version number on it (1.35.0 instead of 1.34.0). This is easy enough to fix, but I'm afraid this might be an indication of an errant merge of code, or of the branch somehow getting reset/moved.
That was most likely me :(. I fixed an issue with the serialization library aliases and then updated the 1.34 branch with the fix, hence the 1.35 version. Looking at Jamfile.v2 from the web CVS viewer, I can see Jamfile.v2 when selecting the RC_1_34_0 sticky tag. I don't understand what you mean by "no longer in a branch" because I can see it there. How do I fix that problem? There should be an e-mail sent to boost-cvs and boost-build about the submitted changes, but I am getting a Mail Delivery Failure for my sourceforge user e-mail. I have a support request about this that the sourceforge team is looking into.
Whomever has been doing recent checkins to CVS please verify your changes on the branch and fix any problems ASAP.
I'm afraid I don't know how to fix this one as I don't understand how CVS branches work. I understand the concept of branches and merging from a Perforce PoV, but not how that relates to CVS. I am currently using TortoiseCVS. Do you know if WinCVS is easier to use for branching? - Reece _________________________________________________________________ Try Live.com - your fast, personalized homepage with all the things you care about in one place. http://www.live.com/getstarted
Reece Dunn wrote:
Rene Rivera wrote:
Whomever has been doing recent checkins to CVS please verify your changes on the branch and fix any problems ASAP.
I'm afraid I don't know how to fix this one as I don't understand how CVS branches work. I understand the concept of branches and merging from a Perforce PoV, but not how that relates to CVS.
Hm, how to best explain this... Classically, as in revision control lingo, CVS uses inplace branches. Think of them as having all those Perforce branches overlaid onto the same file tree. And what you use to differentiate them, instead of the repository paths in Perforce, is a virtual keyed path on the version number. For example, for the boost/Jamfile.v2 file there's a branch with version number 1.32.2.1 that branches from version 1.32 (usually all branch use x.y.2.z as the version). The easiest way to interact with CVS, and most other implace branching RCS systems, is to check out the branches to separate physical branches (i.e. directories) in your hard drive. For example I have: \DevRoots\Boost\boost - Boost HEAD \DevRoots\Boost\boost_1_34_0 - Boost RC_1_34_0 branch \DevRoots\Boost\website - Boost next gen website HEAD \DevRoots\Boost-Sandbox\boost-sandbox - Boost Sandbox HEAD \RSI\... - My company RCS checkouts \Sourceware\src - Binutils HEAD \STLport\STLport - STLport HEAD \STLport\STLport-5.0 - STLport STLPORT_5_0 branch \STLport\STLport-5.1 - STLport STLPORT_5_1 branch ...and a few more I can't mention :-) That as opposed to having to switch the same set of files back and forth between different branches. Now back to Jamfile.v2. Once upon a time it had the following versions... [branch], (tag): 1.32 -->1.32.2.1 ---[RC_1_34_0] | 1.33 ---(merged_to_RC_1_34) | 1.34 Now it has this: 1.32 -->1.32.2.1 | 1.33 ---(merged_to_RC_1_34) | 1.34 | 1.35 -->[RC_1_34_0] Notice how the branch moved. This is possible because those branch names are really just special cases of tags in CVS, read that as "it's a kludge". Normally there would also be revisions 1.32.2.2 and 1.32.2.3 to match 1.34 and 1.35 respectively as each person who change the file merged into the branch. Now to fix it...
I am currently using TortoiseCVS. Do you know if WinCVS is easier to use for branching?
TCVS is marginally more convenient to use. WinCVS, if you have the Python and TCL extensions enabled, has some nifty commands available. As for branching the are both about the same. That is they are both equally restricted by the terrible branching model of CVS :-) OK the fixing it part with TCVS as that's what I use most of the time (I also use WinCVS and the CLI). 1. Move the branch back onto the 1.32.2.x version tree. a) Select the "Update Special..." command on the Jamfile.v2 file only. b) Specify the "1.32.2.1" version in the "Get tag/branch/revision:" field and hit "OK". c) Select the "Branch..." command on the Jamfile.v2 file only. d) Fill in "RC_1_34_0" for the branch name, select the "Move existing branch" option, and hit "OK" 2. Redo the merge, as outlined on the Boost procedures. a) Select the "Update Special..." and update the Jamfile.v2 to the RC_1_34_0 branch. b) Select the "Merge..." command on the Jamfile.v2 file only. c) Specify "merged_to_RC_1_34_0" as the "Start:" and "HEAD" as the "End:", and press "OK". d) Verify the changes by at minimum doing a diff, and at best doing some testing :-) Select the "CVS Diff" command on the Jamfile.v2 only. In my case it launches WinMerge to show me the changes. e) Fix the errant "1.35.0" change. In my case by pressing the copy-to-right button in WinMerge on that line. f) Select the "CVS Commit..." command on the Jamfile.v2 file only and check in with an appropriate comment. Yes aways comment! g) Move the "merge_to_RC_1_34_0" tag... Switch to the HEAD code, in my case just by going to someplace else on my drive. h) Select the "Tag..." command on the Jamfile.v2 file, and set the "merge_to_RC_1_34_0" tag, select "Move existing tag" option, and press "OK". It's done, and yes I was doing the above live, so it's literally already done in CVS :-) PS. Make use of the revision graph display. It helps to understand what it's really doing under the hood. And of course as Dave mentioned, learn the CLI tools also. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
participants (2)
-
Reece Dunn -
Rene Rivera