Re: Subtree mergeinfo -- what I learnt at the Hackathon

On Wed, Jun 20, 2012 at 11:39 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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.)

I agree with many of the cranky old-timer's concerns ;-) I'm all for
pursuing merge improvements, but what we have short term is this: The
symmetric merge work thus far doesn't handle subtree mergeinfo, but we
want to make it the default for merge, so we're thinking of just
tossing off errors for what it (symmetric merge) can't handle,
changing the default behavior of merge since 1.5. That might be ok if
the "much larger rethinking of Subversion's fundamental merge
philosophy" were already well underway and we had reason to hope that
subtree renames were on the cusp of being addressed...but we are not
anywhere near there that I can tell. So that leaves us with merge in
1.8: "Now without --reintegrate, but with --merge-option-to-be-named
that allows you to merge to targets with subtree mergeinfo".

-- 
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba