Hello everyone,
I'm currently working on the commons-diff-api to add new capabilities in
case of conflict. Yesterday while I was working on it, I added new tests
to check my changes and discovered that our current implementation of
the 3-way merge was not following a "standard" implementation, and so
some expectations I could have was not followed.
Actually Thomas did a huge job by implementing by himself the 3-way
merge based on the diff of previous-current and previous-next, but AFAIU
this implementation does not take into account the diff current-next
which can also bring information.
So for example if you try to do a merge, with the following lines:
origin="Once upon a time","a wolf","started to walk","in the forest"
next="Once upon a time","a wolf","dressed in black","in the forest"
current="Once upon a time","a wolf","started to walk","dressed in
black","in the forest"
the current result will be:
"Once upon a time", "a wolf", "dressed in black", "dressed in black",
"in the forest"
instead of treating it like a conflict which can be view as a more
"standard" answer.
Here by standard, I mean the result that a tool like "diff3" or git
merge would do. I dig a bit on internet yesterday and apparently diff3
is really considered as the standard implementation of a 3-way merge.
I performed the check with those lines both using git and diff3 and in
both cases, they see the "started to walk" as a conflictual line:
Once upon a time
a wolf
<<<<<<< HEAD
started to walk
=======
>>>>>>> 20b7776... My change
dressed in black
in the forest
I assume we could debug the implementation Thomas done to ensure this
usecase is taken into account, as far as I can see it's not easy, but I
guess it's possible.
Another solution, which I personally prefer, would be to rely on an
existing implementation of a diff3 merge, or Git merge: I found
yesterday that jgit have their own Java implementation of the merge
(https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeAlgorithm.java)
and AFAICS the license doesn't prevent us to reuse it (it's a derived
BSD license). I don't think we cannot completely reuse it as it is, but
it's at least a good inspiration to do our own implementation based on a
standard. A better solution would certainly to use a dedicated
maintained library but I did not manage to find it.
Now we could also assume that the current behaviour of the merge is what
we want and we keep up with it.
So what do you think, should we change our implem or keep it like that?
Simon
--
Simon Urli
Software Engineer at XWiki SAS
simon.u...@xwiki.com
More about us at http://www.xwiki.com
