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