-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> Hello John. Ignoring bug#494197, I continued my tests.
> 
> 1) using the same weave merge as the one I described in a previous post ("frazer" into "sp1r-tomas"), I checked a few text-conflicted files, comparing:
> - the file with its inline TREE/MERGE-SOURCE markers
> - the merge done by "bzr extmerge" (using kdiff3) which uses the BASE/OTHER/THIS files 
> (BASE being the one which your branch nicely produces).
> They produce similar results, which suggests that your new BASE file looks good.
> A detail: I could observe that when the inline-markers file shows a conflict, 
> sometimes extmerge/kdiff3 would automerge correctly, and
> sometimes extmerge/kdiff3 would automerge wrongly (which is the
> worse thing for us - it introduces bugs silently). It's
> not a problem in bzr as extmerge/xxdiff does find a conflict
> (so it's rather a problem in kdiff3, which I reported to the
> maintainer).


Well, the .BASE file is a bit artificial, which means that there is
probably some amount of work that bzr could try to do to encourage
appropriate behavior with the external merge tool.

I know of one case specifically for --lca merge and how it generates
conflicts and marks lines. Specifically if you have:

 A
 |\
 B C
 |X|
 D E

With texts:

A:
foo
bar

B:
foo
b line
bar

C:
foo
c line
bar

D:
foo
b line
c line
bar

E:
foo
c line
b line
bar


In this circumstance:

1) bzr merge --weave of E => D will give E text, and D => E will give D
text. (So the direction of the merge changes the result, which is
usually not great.)

2) bzr merge --lca will conflict, and either preserve "b line" or "c
line" (based on direction), and mark double conflicts for the other
line. So you will get

foo
<<<<<
c line
=====
>>>>>
b line
<<<<<
=====
c line
>>>>>
bar

When figuring out the BASE for this, we can generally either do:

foo
b line
bar

Which causes a 3-way merge to end up with

foo
c line
b line
c line
bar

or We can start with a base of

foo
c line
b line
c line
bar

Which causes a 3-way merge to end up with

foo
b line
bar

Neither is great, as the 3-way tool resolve an --lca conflict with a
unconflicted but doubled (or removed) result. I chose to implement it
such that it omits the lines in BASE, so that they show up in the merge
result. (Easier to delete lines from the result than add lines that were
removed.)


Now, I can also quickly show places where weave works successfully but
- --lca fails, and similarly for 3way merge versus --weave. So there will
always some cases you get wrong.

If you go back to:
http://revctrl.org/CrissCrossMerge

It reminds that under the same circumstance as listed here 3-way merge
with A as a base gives double conflicts, with B or C as a base gives a
"incorrectly clean" result. (More importantly it does this even when the
texts are significantly altered.)

So this may not be a specific bug in kdiff3, just a limitation of 3-way
diff and some difficulties with BASE selection.

John
=:->


> 
> 2) I did a big merge (133 conflicted files) of two other trees, which
> was *not* criss-cross; I see merge3 and weave give the same BASE files
> with same content, which is good.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkshKDAACgkQJdeBCYSNAAMu+gCeN2XhtEfva0pgFy6Oi+ya3VE/
6MkAoIRUh4ud3WCHgmfWhOf7IUTjc/Ge
=f2VB
-----END PGP SIGNATURE-----