Re: Subtree mergeinfo -- what I learnt at the Hackathon

On Wed, Jul 11, 2012 at 7:44 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Branko Čibej 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)?
>
> No; the inheritance algorithm is simple enough.
>
> This discussion is about how to compare what "works" now (in 1.7) versus what "works the same" or "works better" or "works worse" in a proposed "symmetric" implementation. It's a matter of devising a way to enumerate all the possible the cases systematically, so that we have a way to answer the question "do all the cases that work in 1.7 still work in the proposed implementation?"

Totally agree with what you are doing here, particularly the "do all
the cases that work in 1.7 still work in the proposed implementation?"
part. What remains an open question is what we do if something that
worked in 1.7 no longer works in the proposed implementation -- and
obviously we know about some of these cases already.

-- 
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba