> -----Original Message-----
> From: Julian Foad [mailto:julianf...@btopenworld.com]
> Sent: maandag 7 april 2014 12:32
> To: Bert Huijben
> Cc: 'Daniel Shahaf'; 'Lev Serebryakov'; dev@subversion.apache.org
> Subject: 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.
+1 on the idea of improving the merge information..
But how this eventually should end up in 'svn' depends really on the
question:
* Is the file containing the markers the place to learn about the different
sides or is it just a file created to allow easy resolving.
The file only contains the information about the conflicting hunks, while
you would really need to know about all changes to decide what to do. And in
that respect the 'svn resolve' interactive resolver provides much more
information.
Before 1.7/1.8 we couldn't really restart the resolving after an operation,
but this is now a much better tool to resolve conflicts than we can ever
create in a plain text file.
>
> > 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.
Essentially a merge is incorporating the changes between LEFT and RIGHT into
the PRISTINE file.
But as we support merging into a locally changed file we just ignore the
PRISTINE file and use the original WORKING as if it were the pristine file.
That doesn't make the difference between PRISTINE and WORKING not
interesting... It still contains the important notion of what is really an
uncommitted local change (MINE) vs what was already there on checkout
(BASE/PRISTINE).
Sure there are even more interesting revisions if you know the full graph of
changes, but the merge code in libsvn_wc just knows these 4
files(PRISTINE,LEFT,RIGHT,WORKING), and produces a MERGED file from them:
and a Boolean conflicted vs not conflicted.
I'm pretty sure that you need more than a plain text file GUI to add the
notion of more than 3 trees in a way that our users are able to understand
it.
But I'm thinking that calling either LEFT or PRISTINE 'original' in the
MERGED file is not really going to help our typical user.
And I wish my merge tool was smart enough to really understand 4 inputs...
Showing LEFT as the older version is showing a lot of non-changes as if they
were interesting for the merge, while they could have been filtered as
unrelated with access to PRISTINE.
Bert
>
> 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
