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.
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
Received on 2010-01-22 13:52:52 CET