[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 12 Sep 2012 11:28:10 -0400

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.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2012-09-12 17:28:48 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.