On 12.09.2012 17:28, 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.
It appears that we're looking at introducing a new kind of history
tracking operation. Currently we have "revise", "move", "copy" and
"branch"; and what you're describing I'll call, for the sake of brevity,
"split", a kind of lightweight, source-change-transparent branch. As you
say, there's a use case for both "copy" and "split"; but I'd prefer to
see them both supported at the same time, rather than having a knob
that turns "svn copy" into one or the other. Whether this happens by
introducing a new comand, adding an option to curent "svn copy", and
which behaviour is the default, is a matter for discussion.
-- Brane
P.S.: I've argued on and off for years that "svn branch" should be a
separate primitive. Maybe introducing yet another semantic for "svn
copy" will finally make that point obvious.
P.P.S.: There's a valid case for also having the reverse of "split",
i.e., "join", which implies that the contents of several different files
were merged into one. I'm sure Julian will love the implications that
would have on merge tracking.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2012-09-13 14:35:56 CEST