Re: tree conflicts: incoming delete of a folder

Julian Foad wrote:
> On Tue, 2010-01-19, Neels J Hofmeyr wrote:
>> Hi TC fans,
>>
>> I've been digging into diff again, aiming at that missing tree-conflict
>> detection: 'Incoming delete of a folder will also delete a folder that
>> locally differs from what was originally deleted.'
>>
>> I'm facing this question;
>> Obviously we want to enforce this rule:
>>
>> 1. An incoming delete of a folder is a tree-conflict when it would delete a
>> folder structure that is different from what was originally deleted.
>>
>> But, it is thinkable that the BASE of the working copy was different from
>> the incoming delete, and that there were local changes made so that it now
>> looks exactly the same as the incoming delete. In that case the incoming
>> delete would discard all local changes. Technically, no content would be
>> lost, since the exact same content exists in the repos, i.e. just before the
>> incoming delete.
>
> Yes.
>
>> But it's in principle not very nice to do that.
>
> Why? Because it is "deleting local mods"? Although that sounds "wrong",
> I think that is only because the word "delete" has connotations of a
> scary destructive thing, whereas it is just a perfectly normal and
> intentional change like any text mod is.
>
> If we say it is "applying the incoming change to the local version" or
> it is "combining the incoming change with the local change", does that
> sound better?
>
>> Currently, I think we have this rule implemented:
>>
>> 2. An incoming delete of a folder is a tree-conflict when there are
>> *uncommitted changes* anywhere in that folder in the working copy. This is a
>> tree-conflict even if the WC's local modifications yield a structure and
>> content identical to the structure and content that the incoming delete
>> originally deleted.
>>
>> Do you agree that we should keep rule 2 in place?
>
> No.
>
> The danger of rule 2 and the advantage of rule 1 comes when we try to
> apply multiple changes in sequence. We should always strive to make it
> possible to do one merge after another (or one update after another),
> and the end result of the sequence should be the same as if we just did
> a single merge (or update) that brought in both of the changes at the
> same time.

Fair point! I agree there.
So as soon as diff_wc_url-summarize is up to checking for rule 1, we can
drop rule 2.

Rule 1 does not include differences in history, right? Obviously it doesn't,
just making sure. It does include differences in content and in props.

Thanks,
~Neels

>
> We need rule 1 to make that sort of thing work properly.
>
> Or, looking at it another way, the important thing is to keep the
> concept of merging (and updating) clean: the concept is that the
> incoming changes are applied to the working version, and we should try
> very hard not to special-case the behaviour of any particular kinds of
> local mods or incoming changes.
>
> - Julian
>
>
>
>> (That would imply that we don't need WORKING to check for differences. When
>> we know there are no mods, we can diff *BASE* against the URL. We'd still
>> need diff_wc_url-summarize, since it could be a mixed-revision WC.
>> I'm currently busy checking validity of diff_wc_url, with the intention of
>> eventually implementing --summarize for diff_wc_url, as I had once started
>> to do back in the days.)
>>
>> Thanks,
>> ~Neels
>
>