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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-16 22:23:05

----- Original Message -----
From: "Jim Hyslop" <jhyslop_at_[hidden]>

> > 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?

The latter, in this case.

> 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.

See how complicated this all is? I'm really dissatisfied with this
scenario. Someone needs to write a front-end for CVS that makes these
issues disappear. You should be able to do:

    cvs-merge-from <branch-tag-name>

To merge any unmerged changes from the given branch into the working copy
(which may be on another branch) and makes any neccessary records so that
you can do:

    cvs-commit

which commits the working copy and makes any neccessary records so you can
keep doing this forever.

-Dave