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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-05-16 03:49:08

David 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.
>
> 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 trying to understand your question..... do you refer to the following 
situation:

1. You merge from branch to trunk
2. Somebody else comitts something to the file you've just merged
3. You move *_last_merge and the unmerged change is marked as if it were 
merged.

This should be rare, because the time between 1 and 3 is quite small, and you 
merge only specific files. 

I can suggest the following way of handling it, if you want

1. Switch to branch, and after making sure that the current state is what you 
want to move to trunk, create a tag, for example:
cvs tag RC_1_28_0-mergable-state-dwa
2. Switch to the trunk and do
cvs up -j RC_1_28_0_last_merge RC_1_28_0-mergable-state-dwa
3. Commit
4. Swtich back to branch
cvs up -r RC_1_28_0-mergable-state-dwa
5. Move the last_merge tag
cvs tag -F RC_1_28_0_last_merge

This way, you won't move *last_merge tag past the changes to the branch that 
you've merged. There's still race condition here, in case someone else 
decides to do the merge of the same files at the same time, but that is too 
rare. 

- Volodya