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.
> 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. I would love to see Julian move forward with this
work and am looking forward to learning how far it could get us.
Received on 2012-06-20 19:26:17 CEST