Bob Paige <[email protected]> wrote:
> [-- text/plain, encoding 7bit, charset: ISO-8859-1, 88 lines --]
> The root of the problem seems to be these phony conflicts. I've only done a
> merge once (our release guy usually does them) and it is painful. I guess
> that is why he wants to avoid the phony conflicts.
Hm, you must be leaving out a step. The first time you merge from
branch to trunk, you can do
cvs update -A # back to trunk
cvs update -j branch_tag
and fix conflicts, commit. The second and subsequent times, you have
to do something else to avoid reapplying those changes.
First: put a tag at the tip of the branch from which you just merged.
cvs tag -r branch_tag branch_MERGED
Later when more work has been committed to the branch and you want
to fold it into the trunk, you do something like this:
cvs update -A # back to trunk
cvs update -j branch_MERGED -j branch_tag
fix conflicts, test...
cvs commit
cvs tag -F -r branch_tag branch_MERGED
The idea is to always leave a tag behind you, here "branch_MERGED",
at the point on the branch from which you just merged. The next
time around, this allows you to use the two "-j" form of update
and merge only from the previous merge point to the new tip. You
move the "branch_MERGED" tag after each merge; the "-F" option is
necessary because the tag already exists.
CvsNT keeps track of the last merge point automatically (in the
log message, I think) but I'm not sure how to make use of it.
Unix cvs doesn't and you have to manipulate a tag yourself.
--
pa at panix dot com
