Re: Merging changes between branches

[Pierre Asselin]

In <address@hidden> "Yuval Rotem" <address@hidden> 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).