On 06/20/2012 10:59 AM, Julian Foad wrote:
> HOW SHOULD SYMMETRIC MERGE BEHAVE?
>
> What does this mean for how the initial implementation of symmetric merge
> should behave?
>
> My intention so far has been to make the 'sync-like' direction of
> symmetric merge (that is, same direction as previous merge) behave as a
> backward-compatible replacement for the current 'sync' (that is,
> non-reintegrate, merge-tracking, unspecified minimum revision) merge.
>
> However, I don't want to fence us in to a new behaviour with the same
> backward-compatibility guarantee with regard to subtrees. So now I'm
> thinking maybe a plain symmetric merge should error out if there are
> subtrees (that have different eligible revision ranges from the root).
> What would the command-line UI look like? A plain "merge" errors if
> subtree merges are needed, while an option forces it to handle them (in
> the current fixed-relpath way)? And then in the future we remove the
> restriction if we come up with a good way to handle them?
So ... in order to avoid a *possible* change of default behavior in merge
subtree handling in the future to incorporate arguably better merge
semantics, you wish to *absolutely* change the default behavior in merge
subtree handling today in an unquestionably backwards-incompatible way?
This seems ... odd. What am I missing?
But let's back up a bit, though.
I'm not convinced that the changes you wish to make to subtree handling are
all that desirable, at least when not considered as part of much, much
larger rethinking of Subversion's fundamental merge philosophy.
Subversion's merge is, as you know, at it's core a very simple diff + apply.
Always has been. Merge tracking merely helps humans keep track of which
diffs have already been applied. And diff + apply -- in Subversion merge as
in `diff | patch -p0` -- is about as naive when it comes to handling the
individual ancestries of merge target subtrees as it comes.
Why, then, should an automatic subtree "fix-up" (or "catch-up" ... I don't
know the right term here) merge pay special attention to rename history --
and even then, still only do so for the root of that subtree -- when the
rest of Subversion's merge functionality will carry on just as ignorant of
subtree ancestry as in Subversion 1.0? It appears to me that you'll be
adding complexity and cost to partially solve one edge case, all the while
making Subversion's merge behavior just that much less comprehensible to the
average user who'll be knocking on the users@ door trying to figure out
what's going wrong with his or her merges.
I agree that Subversion could benefit from a complete revamp of its approach
to merging. diff + apply works fine up to a point, and I think we all sense
that renames in the history of the source and target trees are probably that
point. If we're going to move past that point, though, we're going to need
to reconsider Subversion's fundamental diff + apply merge philosophy.
(Sorry if the above reads like a cranky old-timer putting the brakes on
progress -- I trust you know that's not my intent.)
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-06-20 17:40:44 CEST