The phenomenon described by the blogger is typical of a situation where
the common ancestor is not identified correctly. What happens is that
there's the "real" common ancestor, and the (incorrect) version that
the user identifies as the common ancestor. During a 3-way merge, the
difference between the "real" common ancestor and the user's
specification is lost. If you do the math, what happens is that the
delta between the user's specification and the top of its branch is
applied to the target branch. That delta does not include the
difference between the specified ancestor and the real one. Hence, it
is lost.
So, it's important to tag the committed result of every merge, avoiding
race conditions (i.e. use "cvs tag" on the workspace from which the
merge was committed, not "cvs rtag"), and use that tag as the ancestor
for the next merge. This is explained somewhere in the documentation.
On Jun 20, 2006, at 10:40 PM, Spiro Trikaliotis wrote:
Hello,
* On Wed, Jun 21, 2006 at 07:30:14AM +0200 I wrote:
looking through one blog I regularly visit, I found the following
problem description about CVS:
and sorry for using a wrong subject; I pressed "send" to fast.
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://opencbm.sf.net/
http://www.trikaliotis.net/
http://www.viceteam.org/
_______________________________________________
info-cvs mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/info-cvs
--
Paul Sander | "Lets stick to the new mistakes and get rid of the
old
[EMAIL PROTECTED] | ones" -- William Brown
_______________________________________________
info-cvs mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/info-cvs
