Re: Three-way merge markers by default
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 7 Apr 2014 13:53:36 +0100 (BST)
Bert Huijben wrote:
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
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,
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
Again, we understand the same thing in different ways.
> Sure there are even more interesting revisions if you know the full graph of
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
> But I'm thinking that calling either LEFT or PRISTINE 'original' in the
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.
This is an archived mail posted to the Subversion Dev mailing list.