On Fri, Apr 20, 2012 at 1:12 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Hi Paul, just one clarification request on a very brief skimmed reading:
>
>> * If the incoming change deletes the path SS, then it is interpreted as
>> deleting the entry SS from SSP's list of children.
>>
>> Correct, SS_at_BASE is deleted, *but* the repository location represented
>> by the switched subtree is also deleted -- Both are deleted.
>
> Are you saying that if we commit this merge, it will delete the repository path SS from SS's parent-in-the-repository, and also delete the repository path SS_at_BASE from SS_at_BASE's parent-in-the-repository? Well, I never would have guessed that!
Yes, that's what I'm saying. Again, merge has always worked this way,
nothing changed with the advent of merge-tracking.
Arguments can be made for either deletion I think:
1) Deleting the base: Unlike an edit to SS, a deletion doesn't require
the base, so even though the it's not "present" in the WC the merge
wants us to delete it, so we do.
2) Deleting the switched path from its parent-in-the-repostitory: If
this was an edit we'd make the change, why not with a delete?
Not saying this is ideal, just that when we are presented with this
particular use case this is what happens. Honestly I'm not sure what
the ideal behavior should be!
Paul
>> Not sure
>> what the ideal behavior is, but this is nothing new (it pre-dates
>> merge-tracking). Honestly this particular use-case fell through the
>> cracks, I don't recall it ever being discussed.
>
> OK, and thanks for the details; I'll study the rest on Monday.
>
> - Julian
Received on 2012-04-20 19:26:15 CEST