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
