On 06/20/2012 01:25 PM, Stefan Sperling wrote:
>> (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.
I agree that it doesn't help as much as you or I would like. Still, I'd
like to think that you'd appreciate my pointing out that the petroleum I see
dripping from beneath your car might be a reason to avoid driving it, even
when I lack the mechanical know-how to prescribe a more specific solution. :-)
Having attended and listened intently -- expectantly, even -- to Julian's
presentation in Berlin, I find myself in a very awkward situation. On the
one hand, I appreciate (greatly!) that somebody besides Paul is looking at
the merge code at a deeper level, and I love the goal of making merge
tracking easier to use and use right. But my understanding is that thus far
the feature hasn't come anywhere close to its full potential, and that what
we've mostly accomplished is to make the very simplest of the
not-absolutely-trivial merge scenarios (whole-tree, at-the-branch-root-only
merges) a bit simpler. And the less simple ones -- those are to become
errors now, with only a sketch of a half-baked idea about how we might deal
with them later?
I too would love to see Julian move forward with this work, and I don't want
to be a voice of discouragement for that effort. It's just the moving
backward that bothers me. Error messages communicate to users that they're
doing something wrong, but they aren't. Support for subtree mergeinfo and
cherry picking are a documented part of Subversion's merge tracking feature.
I dunno. I've tried to convince myself that this is similar to the change
we made in 1.7 to require a uniform revision number in the target tree. But
that feels different to me. That change was made to help folks avoid
getting into the subtree mergeinfo business unnecessarily. This change just
repeatedly penalizes folks who are already in that situation.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-06-21 04:07:58 CEST