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
Received on 2012-07-11 13:48:16 CEST