On 26.11.2014 18:24, Stefan Sperling wrote:
> On Wed, Nov 26, 2014 at 04:53:00PM +0000, Julian Foad wrote:
>> I recognize that this all seems a big change, but I think it's the most
>> important thing Subversion needs, and I think we can do it. If you care about
>> move tracking, please have a play with it and tell me what do you think.
> I'd really like to look at this but there is something at a higher
> level that worries me and discourages me from diving into technical
> details just now.
>
> I remember Branko telling me last summer he had a vision of how moves
> would work and that it was different to yours and that merging moves
> were not going to work as you envisage. (That's not exactly what he
> said, I'm just paraphrasing what I took away from the conversation.)
This does pretty much capture what I meant, yes.
I think the most important aspect on which Julian and I disagree is the
idea that branches must be declared, and moves restricted to a branch,
in order to make move-aware merges (and hence moves) work reasonably
well. My counter-argument to this is that, because of the long history
of Subversion in the wild, where there are no declared branches and
moves tend to happen any which way; in order to preserve backward
compatibility and the semantics of existing repositories; we /must/ find
a way to make merging work in the presence of cross-branch moves (for
the current, or any other definition of a branch).
I'm not opposed to introducing a first-class concept of a branch; in
fact, I believe such a thing could vastly simplify our branch/merge UI
and prevent a large class of "mistakes" that users tend to make. But I
insist that such a feature is orthogonal to solving the problem of moves
and move-aware merging.
**
I'm also convinced that our current object model already has all the
information needed to resolve any kind of merge scenario, even the
"follow-moves" problem and cross-branch moves. The drawback of the
current model is not lack of knowledge, but the cost of extracting
certain kinds of knowledge from the repository, which in some cases
would devolve to a full-graph traversal. This leads me to suspect that
the "correct" solution will involve denormalizing the object model in
order to make these queries faster; probably also moving some part of
the merge algorithm to the server, which has all history at its fingertips.
Julian's solution to this problem is to invent a branch-specific element
ID, which would be used by the merge algorithm to match related nodes on
different branches. This clearly works to some extent, within the
constraints of the declared-branch feature; but I've not yet been
convinced that it's a viable solution if you take upgrading repositories
with deep histories into account. Specifically, in our model, any node
can be a member of any number of nested branch-families; yet the element
ID solution only works if these IDs are unique within any branch. At
that point, I fail to see how the element ID concept is better, or
perhaps even different, from the existing node-id.copy-id pair.
All the above said, Julian's work on the move-tracking-2 branch is
extremely useful: we now have a working prototype of one possible
solution to the move problem, and even more important, we have a working
editor API that can theoretically handle any sequence of moves
(something that we found Ev2 could not do).
> Since then I haven't heard much from Branko on this topic,
I hope I just fixed that. :)
> I have put
> off work on a more user-friendly tree-conflict resolution script I've
> been meaning to write (other projects have just been so much more exciting),
> and you've been hacking away on this branch which is great but...
>
> ... are we still a project run by a community of collaborators with a
> shared focus, or is everyone of us working isolated in their own corner?
Move tracking and merging is the sort of specialized problem that very
few people understand. As such, it's kind of hard to collaborate on a
prototype solution. I'm sure Julian didn't mean to heave a code-bomb on
the community. It just looks that way, because any solution will, almost
by definition, look like a code-bomb. :)
> In the latter case, what do we do to fix the situation and find
> project-wide consensus on how to proceed?
>
> What's the grand vision that unites this design with other (as of
> yet mostly vocally relayed) design proposals? I've never seen the
> discussion about competing move-tracking designs that took place
> in Berlin earlier this year being concluded.
Indeed, it's never been concluded here on this list. That's because it's
way too early to conclude anything; we have yet to properly understand
the problem, let alone agree on the solution.
-- Brane
Received on 2014-11-26 19:32:01 CET