Boost logo

Boost :

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
>> 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
>> candidate file. What is the procedure so that at completion:
>> * Both the repository main trunk and release candidate branch have the
>> fix applied.
>> * The developer's working copy is set back to the main trunk again, and
>> 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
>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> \
> 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
>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
>location or clean before you build, since there may be old objects
>Commit your fixes. In a directory no lower than the highest directory
>you made a fix:
> cvs commit
>CVS will bring up a window with a list of the files you've
>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.
>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?



Boost list run by bdawes at, gregod at, cpdaniel at, john at