Jan Hudec wrote: > On Tue, Jul 12, 2005 at 11:12:14 -0700, Thomas Lord wrote: > >>I'm very skeptical of "the Codeville merge algorithm" for reasons >>not terribly important here. Let's stipulate, for the sake >>of conversation, that it's the greatest thing since toast and, >>additionally, that it imposes a moral imperative on revctl developers >>to optimize-for-annotate. > > > As far as I understand the Codeville merge algorithm, it is a line-wise > 3-way merge.
AIUI, it's line-based, but it's stretching it to call this a 3-way merge, because the three pieces of data are THIS-text, OTHER-text, and the history of both branches. There are now two Codeville algorithms, both described here: http://lists.zooko.com/pipermail/revctrl/2005-May/000005.html I was referring to the new "precice merge", which I'll describe below. Each line is identifiable, and can be given a unique ID. So the merge algorithm doesn't need any textual context to do merging. Any lines that were created in THIS will appear, unless they were deleted in OTHER, and vice versa. It's not a three-way text comparison at all, and I the behavior is different from diff3 if both branches add the same text independently (rather than through merging). > On the other hand, it's better in the case when there is more than one > most recent common ancestor, which is very rare, so it's not really > a priority. It behaves much better in the presence of incomplete merges, i.e. cherry-picking, and I believe it also handles crossed merges well. These are both problematic in star-merge, though I expect crossed merges work better with --three-way. Aaron _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
