RE: [boost] Problem(s) with release procedure

From: Jim Hyslop (jhyslop_at_[hidden])
Date: 2002-05-16 21:03:21

Dave Abrahams wrote:
> Our current merge procedure requires us to keep track of 
> which files have already been merged once to the main trunk. 
> For releases like this one, where lots of documentation 
> changes were made in the release candidate branch, that can 
> be really inconvenient. I suggest we tag each new release 
> candidate branch with RC_<version>_last_merge the moment the 
> branch is established. That way
> 
>     cvs update -jRC_<version>_last_merge -jRC_version
> 
> can always be used to merge to the trunk.
Yes, a branch tag should always have a sticky tag to mark the base of
the branch.

> Also, how do you make sure you tag the correct version of 
> last_merge? Someone can always come in and check in a new 
> version on the branch after you've merged it to the trunk. Is 
> this a serious CVS limitation?
I'm not sure what your concern is - are you concerned that someone will
add changes to the branch, which won't get merged to the trunk, or are
you concerned that the last_merge tag will incorrectly point to the
unmerged version? Or something else entirely?

If the former, then that's beyond CVS's control. Unless... hmmm... if
the intent is to declare the branch "closed to further development" you
might try deleting the (floating) branch tag. Then when the other person
tries to check it in, they should get an error. I haven't tried it, so I
don't know if that will work.

If the latter (i.e. last_merge tag points to the wrong version) then
sticky tags would solve the problem. You work with two sticky tags - one
indicating the last time the merge took place (or the base of the branch
if it's the first merge) and another indicating the most recent version
you want to merge. Using two -j options, like you suggest, will then
work.

-- 
Jim