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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
