How does RTC calculate the common ancestor for a merge conflict?
In ClearCase-UCM, there are some unique edge case merge scenarios involving the "deliver to alternate target" functionality that can cause the ClearCase merge ancestor algorithm to fail to identify the desired common ancestor during a merge operation (multiple valid ancestors, essentially). I have an interesting detailed write up, with a nice visio of the version tree for an example file, if anyone is interested. This was submitted as a bug on version 7.x of ClearCase, but the response was that no fix would be forthcoming.
Conjecture: This may have been an impossible fix to implement, because you can't anticipate every possible strange combination of actions users can perform, many of which might cause your common ancestor calculation to be very complex and time consuming, perhaps even impossible. Not to mention, I would bet by version 7 of ClearCase, the programmers maintaining it didn't want to touch that module.
So, knowing that you can break a merge tool with some fairly plausible edge cases, it would be very useful to understand the limitations of what Rational Team Concert can do with regard to common ancestor calculation. This is particularly interesting, as ClearCase-UCM relied on it's parent/child relationship to perform calculations (the "bug" that was submitted highlighted this weakness), but RTC has no strict parent/child relationship between various streams. In fact, you have even more flexibility in structure than ClearCase did.
Is there a tech document on this algorithm?
|
Accepted answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Feb 24 '14, 10:58 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited May 18 '16, 2:57 p.m. by David Lafreniere (4.8k●7)
RTC-SCM uses the predecessor (child-parent) relationship between versions to determine the common ancestor. The algorithm before 4.0.6 was "nearest common ancestor" (defined by a breadth first search of the predecessor relation). In 4.0.6, you will have the option to switch to "latest common ancestor", which is (as you might guess) the most-recently created common ancestor. This behavior is governed by an 'advanced property' on the server called "Enable Lowest Common Ancestor" (which has a default value of 'false').
David Lafreniere selected this answer as the correct answer
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.