problems with vc-merge.

Uwe Brauer writes: Hm. I would have expected you to get something identical to version 1.5. More on that below. A merge is not an operation on two version; it is operation on two patches to the same version, or equivalently, an operation on *three* versions. Normally the two versions that are apparently being merged are on different branches, and the third version is usually computed as the common ancestor: B--C We want to merge C and E. So we trace back from C through B, / and from E back through D, to A, the common ancestor. Then A we take all hunks of the diff A->C that do not touch lines \ touched by the diff A->E, and apply them to A. Similarly we D--E take all hunks of the diff A->E that don't touch lines touched by the diff A->C, and apply those to A. Finally, if there are any hunks of diff A->C that touch lines touched by diff A->E, those hunks are *conflicts*, and you must resolve those by editing the file to get the desired result in the conflict hunks. In your case, the graph is trivial: "1.4--1.5", and the (forward) merge would have 1.4 as the common ancestor of 1.4 and 1.5. The patch 1.4->1.4 is empty, of course, so all the hunks of the patch 1.4->1.5 are effective, and you would get 1.5 as the output of the merge. You apparently invoked vc-merge in such a way that vc interpreted as a reverse merge (which can be useful), and you ended up with version 1.4 as the output. For more information, it might be useful to look at "info diff3" and/or "man merge". The ediff manual also might go into some detail. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta