On Mon, 22 Aug 2011 14:36:36 +0000, Stefan Sperling wrote:
...
> In Subversion, a merge is the computation of a delta between two
> arbitary trees, and the application of this delta to some other
> arbitrary tree.
To keep the (vector) addition analogy, you are measuring the difference
from A to B and move C in this direction. Which yields the same as
measuring from A to C and move B in *that* direction. You end up in the
same point. Just once B ends up there, and once C.
Anyway, while that is what you tell, and probably do for directories,
you can't get around using a version of the (symmetrical) diff3 to merge
file contents; that is the only way to sanely apply the delta. An actual
delta (patch) wouldn't generally be applicable to the target file.
> The merge target is *completely independent* of the merge delta.
> There is nothing, in the core algorithm, that would know about stuff
> like merge points and the like.
No, that comes into play when selecting the two revisions and paths that
you need to compute the delta to apply.
> You seem to be basing your mental
> model of merge on tools like git or hg. And that is a very good model.
> But it is very different from what Subversion is doing.
Unfortunately it is not that different from what I expected when
subversion was said to get proper merge support. (I was pampered
by cvsnt, which (once) could do bidirectional merges.)
> There is no merge DAG in Subversion.
> The closest equivalent to a merge DAG is svn:mergeinfo, but it
> doesn't implement a DAG -- it implements a filter that prevents
> the same revisions from being merged twice. That's all.
And unfortunately, it is so simplistic that you need to prod it with
--reintegrate the first (and last) time you merge in the other direction.
(Or it seems so.)
> It is really quite simple at the design level. The implementation
> is not simple because it handles a lot of additional quirks that
> are not reflected in this short and abstract description of what
> Subversion is doing.
Yes, recorded cherrypicking, not to mention all the rename handling.
...
> Let me quote the relevant part of the post I linked to:
...
> Is that clear enough? If not, please ask.
It's not quite. But it seems I need to wade through what actually happens
with the mergeinfo to understand why a backmerge can't deduce the proper
action without --reintegrate, and why the merge info then needs to be
borken for the branch. (Which may be partly simply because you can't
modify the branch's mergeinfo to mark the merge revision on the trunk
as already merged.)
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Received on 2011-08-22 18:33:51 CEST