Johan Corveleyn wrote: > On Wed, Jul 11, 2012 at 6:19 AM, Branko Čibej wrote: >> 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 > ... >
Thanks, Johan, and yes you've described my position exactly. - Julian
