calin.hanchevici@gmail.com 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 _______________________________________________ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs