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

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-05-17 03:28:19

IIRC, the original Tichey(sp) RCS solved (or at least alleviated) some of 
this and the "features" were removed when CVS was "put on top".
I believe there was a way to refer to both the "root" and the latest "head" 
of any label...I'd have to go dig out the old Amiga RCS docs to verify 
this.... this would get rid of the "peculiar" notion of having to anchor 
the "root" of each branch AND have a "branch label".
further, the "state" was settable and/or useable as a filter on most of the 
commands... i.e. you could refer to the latest "release" state on a branch 
for checkout, checkin (would cause a new branch, of course, unless it was 
also the "head"), merge, etc.
I sorely miss the state filtering on checkout.

At any rate, a solution would be to merge from the state "merged" though 
"head" to the mainline and set the state of "head" to "merged".  This would 
could remove the necessity for "floating labels" as well.  I suspect that 
the state code is still in the RCS pieces which are used by CVS, but 
there's currently no way to access the options since they are called 
through the CVS "front end".

At Thursday 2002/05/16 20:23, you wrote:

>----- 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
>
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"