[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bi-directional merge

From: Pierre Asselin
Subject: Re: Bi-directional merge
Date: Sat, 18 Nov 2006 21:40:35 +0000 (UTC)
User-agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (NetBSD/3.1_RC3 (i386))

address@hidden wrote:

> [ ... ]  Thank you Larry,
> how can avoid these kind of problems? 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, not 1.3 and .  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


    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.

pa at panix dot com

reply via email to

[Prev in Thread] Current Thread [Next in Thread]