Re: Research on rename-aware merging -- or rather of ordered (XML) trees
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 12 Sep 2012 19:59:55 +0100 (BST)
C. Michael Pilato wrote:
> Julian, thanks for taking some time to dive into this problem and write up
Thanks, Mike. I'm with you in wanting that kind of behaviour to be available, and I well remember you making this point before.
There is also the possibility that this strategy could be helpful in transitioning from old moves (copy + delete) to new moves, since this could automatically Do The Right Thing for old moves. Or rather part of the Right Thing: it wouldn't help us to correctly identify conflicts related to an old move.
How to translate this behaviour into a workable definition and then into an algorithm is not quite so obvious, and I don't know the answer yet. The difficulty starts with defining a copy: something simple like "a node N2 that is copied from another node N in the same branch" won't do because we don't want to update a copy that was made before the two present branches diverged. If we try adding "that was copied since the youngest common ancestor" or "since the merge-base" then we mean the common ancestor or base of what exactly? Of the branch root node? No, because we want to support subtree merging. Of the node N? Sounds good, but what if N doesn't exist in the other branch, and maybe N was copied (in this branch) from node K which does exist in the other branch?
And if branch1/M was first copied to branch1/M2, and then merged to branch 2, and so branch2/M2 is recorded as copied from branch1/M, should that behave differently from if branch2/M2 was copied from branch2/M?
(Please regard these as rhetorical questions unless you want to have a go at devising a full definition.)
3DM doesn't have a deterministic way to distinguish one copy as the primary copy, as it doesn't have node-id information (whereas we probably will do), but 3DM nevertheless elects to designate one copy as the 'primary copy' and the other copies as 'secondary', and it applies some restrictions to the secondary copies. (I don't quite understand the restrictions or the reasoning for them, but it's something like a secondary copy can take either content changes or structure changes but not both.) All I can tell at this stage is that there may be something there for us to learn.
So it will need some deeper thought, but I'll keep it in mind.
This is an archived mail posted to the Subversion Dev mailing list.