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
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:
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:
which commits the working copy and makes any neccessary records so you can
keep doing this forever.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk