On Wed, Jun 20, 2012 at 1:25 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Jun 20, 2012 at 11:39:40AM -0400, C. Michael Pilato wrote:
>> 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.
>
> If our "merge philosophy" is to not make merge any smarter than diff+patch,
> then it's not a very good philosophy. Let's not try to clinch to that
> approach at all costs but try to enhance it with new ideas.
>
> And I don't understand how Julian's idea would fundamentally change the
> diff+patch approach.
>
> Consider a unified diff which contains git-extension
> headers which annotates renames for all files involved. That is kind of the
> equivalent of what Julian is planning to do, as far as I understand it.
>
>> 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?
>
> I agree here, if what you're saying is that Julian's approach would only
> try to find renames for subtrees with explicit mergeinfo.
> Ideally, we would try to match up all files and directories within the
> merge source and merge target to one another, regardless of whether the
> file or directory in question has explicit subtree mergeinfo.
+1 If we are relying only on subtrees with explicit mergeinfo we face
inconsistent handling of renames as I mentioned elsethread.
>> I believe this would be recursive. Any subtree which doesn't match
>> 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.
>
> But... but... there are plenty people knocking already, almost every
> single day. Are you not subscribed to users@? :)
>
>> 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.)
>
> But it doesn't help much to say something like this without also suggesting
> a viable alternative.
Seriously? So if someone proposes a *change* in behavior, and someone
in the community opposes it or has concerns about it, they can't raise
those concerns unless they have an alternative plan?
Possibly there is some confusion here since Julian is talking about
two separate-but-related things:
1) HOW SHOULD SYMMETRIC MERGE BEHAVE?
Which we need to determine for 1.8.
2) PAIRING SUBTREES BY THEIR OWN ANCESTRY
Which is work yet to be done.
> I would love to see Julian move forward with this
> work and am looking forward to learning how far it could get us.
I'm in 100% agreement, but I don't want to break one thing that works
today (targets with subtree mergeinfo) simply to support an
improvement in another area (deprecating the --reintegrate option with
the symmetric merge improvements).
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Received on 2012-06-20 22:08:59 CEST