In <[EMAIL PROTECTED]> "Yuval Rotem" <[EMAIL PROTECTED]> writes:
>We want to employ branches as a relatively isolated development environment,
>[ ... ]
>However, according to the docs, it seems that using CVS branches for this
>purpose isn't that trivial, at least in one respect: It should be possible
>to perform an update to merge changes from the main trunk into a branch (or
>vice versa). In CVS this requires me to remember when the last update was,
>and update with two -j flags, which is a bit awkward.
For multiple merges from branch to trunk, you plant a moving tag after
each merge.
$ : on the trunk
$ cvs update -jbranch_lasst_merge -jbranch_tip
$ cvs tag -F -rbranch_tip branch_last_merge
It's clumsy, but doable. I'm not sure what to do for bidirectional
merges. This could work:
-- On the branch, periodically merge *everything* from the trunk
since the branch started, planting a moving tag on the trunk
as above. One moving tag per live branch.
-- To merge from branch to trunk, temporarily restore the trunk
to its state at branch creation time and merge the whole
branch.
$ cvs update -jHEAD -jbranch_starting_point
$ cvs update -jbranch
or
$ cvs update -jbranch_starting_point -jbranch_tip
(Use the latter command if files get deleted on the
branch.)
It is essential that you merge all trunk changes to the branch,
otherwise you will lose code. Hmmm, you may not need a moving tag
on the branch if you do it this way, since you always end up merging
the whole branch. Caveat: I've never tried it, and someone (Larry?)
said that CVS would get confused by two -j-j merges without an
intervening commit. Not sure why, though.
Proposals to keep track of previous merges pop up on this newsgroup
from time to time. Usually they entail extending the RCS grammar
(the "newphrase" production in the rcs(5) manpage).
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
