Re: Bi-directional merge

[Pierre Asselin]

address@hidden wrote:

> [ ... ]  Thank you Larry,
> how can avoid these kind of problems? 1.2.14.2 is identical with 1.2,
> but is not identical with 1.3.

When you merged 1.3 ==> branch, it didn't mean that your branch was
logically based on 1.3 .  It was still branched off 1.2 .  Thus,
when you merged the branch back to the trunk the comparison was
between 1.2 and 1.2.14.2, not 1.3 and 1.2.14.2 .  No net changes
on the branch, no changes folded to the trunk.

> Does this mean that I have to correct the problem in revision 1.3,
> commit the changes then merge r1.4 into my branch?

This time, yes.

> Is there a way to avoid this?

By planting a movable tag at the origin of each point that you
merge.  For example,

    branch> cvs update -jbranchpoint -j1        : trunk to branch
    branch> cvs tag -F -r1 LAST_MERGED
    branch> cvs commit

Later,

    trunk> cvs update -jLAST_MERGED -jbranchtip : branch to trunk
    trunk> cvs tag -F -rbranchtip LAST_MERGED
    trunk> cvs commit

Caveat:  I *think* that works.  I *know* that it gets very confusing,
very fast.  I never got bidirectional merges between long-lived branches
to work right.  I recommend keeping your branches short.

http://groups.google.com/group/gnu.cvs.help/msg/71c6c07bdc16ceb5


-- 
pa at panix dot com