On 10.07.2012 23:40, Julian Foad wrote: > I think the essence of this line of thought is: > > We set up all of the possible mergeinfo scenarios, and we see what 'merge' > does, and we see what 1.7 'merge --reintegrate' does, and we debate what > cases are 'supported' versus knowingly 'unsupported', and we see what an > ideal symmetric merge would do. Then we evaluate the current 'symmetric'[1] > implementation against that: does it do "the same as" or "better than" or > "worse than" what a user can do with the existing merge (assuming he/she > chooses the "reintegrate" option appropriately). > > It's not easy to set up all of the possible scenarios: reintegrating the root > but excluding a subtree, for example, can't be done in a single merge > command. Does that mean that scenario is uninteresting? No, I don't think > so. What we can do is eliminate the existing merge command from the set-up > phases of the test scenarios, and set up the desired mergeinfo directly: > "faking it", if you will. Doing it that way separates the concerns: the > question of what the merge command will do, given a certain scenario, is a > separate question from how we can use merges to create that scenario. > > > The question I have at the moment is: Does this approach to evaluation make > sense to you?
Am I correct in assuming that most of this discussion is a consequence of the current implementation of mergeinfo inheritance? I.e., that there are a certain number of hoops one needs to jump through in order to determine which, if any, mergeinfo applies to a particular file (or subtree)? Assuming that retrieving merginfo is expensive (which I gather it is right now) and you want to minimize the number of explicit mergeinfo lookups, your approach makes sense to me. > [1] 'symmetric' -- Urgh! -- we must change the name as the current > incarnation is not very symmetric at all. You can always try --symmetricer ... -- Brane -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
