Re: Three-way merge markers by default

Bert Huijben wrote:
> Julian Foad wrote:
>> +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.

Good question. I suppose we need to decide whether this file is more an API or more a UI. If we decide it's more important to maintain backward compatibility and treat it as an API, then we should not change it, and should provide the requested change another way.

Is your merge tool, or any software you know of, relying on this file's current format?

> 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.

Yes, I agree. Or, to talk about the same level of API, the set of conflict 'artifact' files (filename.mine/filename.yours/etc.) hold the full information needed.

> 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.

[...]
>>  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.

We probably mean the same thing but are describing it in different ways. To me, the essence of a merge is it merges into the working file. That's the purpose, the logical idea, the intended functionality. When there are no local changes the pristine text is the same as the working text but that's just just incidental.

> 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).

Again, we understand the same thing in different ways.

> 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.

Right, but the only reason the WC library needs to know about the pristine version is because that's such a big part of how the WC is architected. (There is no fully abstracted API for accessing the working/actual layer without talking about the pristines.) If you look at the merge logic in libsvn_client, it doesn't care.

> 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.

Very likely.

> 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.

Really? I'm interested in that case. Can you point me to a concrete example?

The 'variance-adjusted patching' paper explains why this sort of problem can be solved by adding the youngest common ancestor into the algorithm, but I cannot yet see why taking account of the WC pristine version is any more useful than taking account of any other version (that is, a committed revision) between the YCA and target versions.

- Julian
Received on 2014-04-07 14:54:14 CEST