Re: Three-way merge markers by default

Bert Huijben wrote:
> Daniel Shahaf wrote:
>>  What do people feel about applying this patch (from the FreeBSD port) to
>>  trunk?
[...]
>> All it does is change the contents of conflict files in --accept=postpone
>> mode: it causes conflict markers to be rendered not as two sides
>>     <<<<<<
>>     mine
>>     ======
>>     theirs
>>     >>>>>>
>> but as three sides
>>     <<<<<<
>>     mine
>>     ||||||
>>     original
>>     ======
>>     theirs
>>     >>>>>>
>>     .
>> I find the latter style much easier to work with --- it is easier for me
>> to "Apply diff(ORIGINAL, THEIRS) to MINE" than to "Compare (MINE, THEIRS)
>> and sort out which parts of the delta to keep and which to reverse".
>>
>> Does this break compatibility somehow?  Scripts have the foo.c.{mine,theirs,
>> merged} files to work with.  As to users, they may already be familiar with
>> the three-way syntax since the interactive conflicts resolver generates it[1];
>> if not, the book could explain the |||||| block like it explains <<<<<< and
>> >>>>>>.

+1 to the suggestion. The current two-way info is pretty difficult to use in any non-trivial case, and the 3-way suggestion is significantly more usable and not much more difficult to understand. Furthermore it is what I expect to see for a three-way merge, and, if I remember correctly, is what I already do see in the interactive conflict resolver.

> Note that while this gives complete information for update and switch, for
> merging there are actually 4 sides instead of 3...
>
> svn merge merges the difference between two files (left and right) into a
> third file (mine), which also happens to have an original version (its
> pristine version).
>
> So theoretically in case of an update and switch the older versions are the
> same file(left=pristine).

It's true that the target file has a pristine version, but the pristine version isn't *particularly* associated with the merge itself.  We merge changes into the working/actual version, and whether I commit local mods before starting the merge makes no difference to the merging procedure or to the desired result. The pristine version is just "the version before the version I'm merging into". The fact that it was uncommitted makes it interesting from a WC management perspective, but not particularly from a merge perspective.

There's another version that's potentially interesting during a merge. In a cherry-pick merge, the source-left version is (typically) not the youngest common ancestor (YCA) of the two lines of history. In that case, the YCA is also an interesting version from a merging perspective. If I were asking to see a fourth version, I might well want to see the YCA before wanting to see the pristine WC version.

    . . . ----L----R
         /
        /
    ---Y---------------B
                        \
                         W

(Y=YCA, L=source-left, R=source-right, B=WC-base, W=WC-working=target)

A powerful UI could of course offer options to display all the potentially interesting versions, and differences between them. But here we're talking only about how to make the default text conflict markers in 'svn' show up, for those users not using a powerful (G)UI.

I don't think it's sensible for a GUI to use the conflict markers we're talking about here -- it should generate its own. (So I don't think this code really belongs in libsvn_wc -- it's here for historical reasons but really it should be in the 'svn' command-line client only.)

> The problem is now: Are you now showing left or pristine as original?
> Or what is "original"?

That's not a problem -- it's exactly the same as in all typical graphical three-way merge tools that users are already using, as well as the interactive conflict resolver. It's easy enough to document it as such, for completeness.

> The answer for update/switch is easy, but I don't think the per file merge
> code knows the difference between the operations. And I don't think our
> users will really understand.
> (I haven't found a merge tool that really uses all 4 versions except of some
> experimental code in our libraries)

The "experimental code" you mention is for a kind of 4-way merge known as "variance-adjusted patching" as described by Karl Fogel in <notes/variance-adjusted-patching.html>. The fourth version involved here is the YCA, not the pristine version.

- Julian
Received on 2014-04-07 12:32:42 CEST