On Wed, Jul 11, 2012 at 6:19 AM, Branko Čibej <br...@wandisco.com> wrote: > 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.
I assume Julian's remarks are not related to "expensiveness of retrieving mergeinfo", but to the difficulty of *creating* certain mergeinfo situations (difficult to create through normal UI commands), although these configurations are still interesting to have as a test fixture (and the merge logic should be able to handle them in a sane way -- and we should be able to specify what the behavior should be). +1, I'd say. Perhaps we should have both: - Tests with artificially created mergeinfo (a bit like "unit tests": we give the merge algorithm some input, and expect certain output; we don't care about how a user would create that input -- also a bit comparable to "synthetic benchmarks"). - Tests with a full scenario of user commands (a bit like "integration tests": we consider the entire application, and treat it like a black box; we only interact with actual user commands -- a bit comparable to "real-world benchmarks"). BTW, great effort, Julian, in trying to categorize these scenarios a bit, and trying to describe the current and desired behaviors, in a rather concise manner. I agree this is the best way forward right now ... -- Johan
