Re: Research on rename-aware merging -- or rather of ordered (XML) trees

C. Michael Pilato wrote:

> Julian, thanks for taking some time to dive into this problem and write up
> your summary mail.  I'll comment only on specific bits that I disagree with
> or have questions about (leaving you to assume that I think I understand and
> agree with the rest).
>
> On 09/12/2012 10:43 AM, Julian Foad wrote:
>> * 3DM describes a set of "functional requirements", while
>> I'll paraphrase and comment on:
>
> [...]
>
>> 4. A node exists in the *context* of its siblings and parent; this
>> context should be preserved in the result.  -- The 'parent' part of the
>> context pretty much follows from (3), while the 'siblings' part of the
>> context is closely related to ordering and so may hardly be relevant in
>> Subversion.  Nevertheless, this idea bears further consideration.
>
> Not sure precisely how/if this applies to Subversion.  But I suspect you're
> right regarding this requirement's meaning in the XML world -- sibling
> ordering needing to be maintained and such.  We can look into it, but my
> guess is that this requirement is disinteresting for us.
>
>> 5. In a copy-vs-modify situation, 3DM chooses that the modification
>> should be applied to all the copies, yet states that this isn't always
>> wanted.  -- In Subversion, I don't think we want to do this; we might
>> want it to be optional, controlled by a flag in a 'merge policy' or by
>> some sort of callback.
>
> I've generally pushed for exactly what 3DM recommends -- that changes are
> applied to all copies.  I want this because of my personal experiences with
> moves and copies in my data sets:
>
> A.  Real moves are moves -- there's only one "copy" to deal with, so
>     the point here is rather moot.
>
> B.  I use copies for two different reasons (and do so quite regularly):
>
>     1. Splitting a file into two.  When this happens, I want Subversion to
>       merge changes intended for the original single file into all the
>       file's current manifestations.  Yep, most of those applications are
>       going to fail with textual conflicts -- that's fine with me.  I
>       still want the chance to review those conflicts.
>
>     2. Templates.  I routinely use versioned template files which are
>       copied (repeatedly) and where those copies are modified.  I would
>       adore Subversion if, upon making a change to my template file,
>       Subversion could propagate that same change to all its copies!
>
> I'm happy to have this behavior optional, but I strongly desire it to be
> available.

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.

- Julian
Received on 2012-09-12 21:00:31 CEST