$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-06-27 22:45:23
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