[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

tree conflicts: incoming delete of a folder

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Tue, 19 Jan 2010 17:54:30 +0100

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. But it's in principle not very nice to do that.

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?

(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-19 17:55:41 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.