Re: [boost] Release procedures?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-24 17:54:30

At 09:32 AM 1/23/2002, David Abrahams wrote:

 >
 >----- Original Message -----
 >From: "Beman Dawes" <bdawes_at_[hidden]>
 >
 >> What would be a help is if you would figure out the command line cvs
 >> procedure for the following scenario:
 >>
 >> Developer's working copy contains the (possibly slightly out-of-date 
with
 >> respect to the repository) main trunk with some new work-in-progress
 >> changes made to unrelated files.  Developer wants to fix a bug in a
 >release
 >> candidate file.  What is the procedure so that at completion:
 >>
 >> * Both the repository main trunk and release candidate branch have the
 >bug
 >> fix applied.
 >>
 >> * The developer's working copy is set back to the main trunk again, and
 >his
 >> or her work-in-progress is still present as are the bug fixes.
 >
 >The easiest way to get it right is to check a separate copy of the boost
 >cvs
 >tree out, and make the fix there. This command line will bring down only
 >code-related materials and save you from making another copy of peoples'
 >pictures and auxiliary documentation:
 >
 >  mkdir release_<version>
 >  cd release_<version>
 >  cvs -d :ext:<username>@cvs.boost.sourceforge.net:/cvsroot/boost \
 >    checkout -r<version>_branch boost/libs boost/boost boost/tools
 >
 >[This assumes that we have a branch tag called <version>_branch for all
 >release candidates of the official Version_<version>. In other words, all
 >release candidates for Version_1_3_2 will be on the branch called
 >1_3_2_branch]
 >
 >If you just want to get everything, just list "boost" instead of
 >boost/libs,... etc.
 >
 >Make the fixes in this new cvs tree
 >
 >Test your fixes. Keep in mind that if you're using Jam
 >with -sALL_LOCATE_TARGET=... that you may need to choose a different 
target
 >location or clean before you build, since there may be old objects 
hanging
 >around
 >
 >Commit your fixes. In a directory no lower than the highest directory 
where
 >you made a fix:
 >
 >    cvs commit
 >
 >CVS will bring up a window with a list of the files you've 
modified/added.
 >Save this list somewhere that you'll be able to get it back later. Let's
 >call that <mod-list>
 >
 >cd back to your regular working tree.
 >
 >When you're ready to bring in all the bugfixes in from the release
 >candidate, first make sure all of your current changes are checked in. 
Then
 >go to the place in your working CVS tree where you did the commit in the
 >release candidate tree and:
 >
 >    cvs update -j<version>_branch <mod-list>
 >
 >All of your fixes will be merged into your current working copy. When you
 >commit, they will go into whatever branch you're on, or the main trunk.

That procedure does seem to work once.  But if you have to make a second 
change to the same file, the 2nd merge results in conflicts.  It tries to 
merge the original change back into the main trunk copy a second time.

I tried several variations on the theme.  The problem always come the 
second time I tried do a merge.  Does a new branch have to be created after 
each merge?  That can't be right - multiple developers would never be able 
coordinate if each was creating new branches every time they apply a fix.

We must be missing something obvious.  Any ideas?

--Beman

--Beman