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 > >
signature.asc
Description: OpenPGP digital signature
