Stephen Butler wrote:
> Hi Julian and other tree conflict fans,
>
> Are you sure we want to allow some TC victims to be deleted
> by update/switch, and some not?
Yes, for the time being. We discussed this before starting issue #3334:
It's better to make this improvement in some cases now (starting with a
case where it's particularly important because the old behaviour was
really awkward for the user to resolve) and improve case by case when we
can.
> The current behavior in the issue-3334-dirs branch, in the
> case of "incoming delete upon update", skips the TC victim
> if it's a directory tree, but deletes the TC victim
> if it's a file or empty dir.
>
> For quite a while we've had the skipping behavior for all
> TC victims. Four tests that fail on the branch,
>
> update_tests.py 47 51
> switch_tests.py 32 35
>
> fail because they expect all TC victims to be skipped.
>
> Our main reason for skipping is to make it easier for the
> user to rescue any local modifications. With your re-add
> feature, this reason no longer exists.
>
> A second reason for skipping is to preserve info about which
> revision of the victim was deleted locally, in the case
> of "local delete". But the extension of the tree conflict
> data to include version info makes this reason obsolete, too.
>
> Can anyone think of any other reason for skipping tree
> conflicts? (Or any other flaw in my reasoning?)
>
> If we can't, then I think we should change the TC design
> and get rid of the skipping entirely. It's a new feature
> that could confuse users, and it goes against the grain of
> the rest of the 'svn update' code. If we can live without
> it, we're better off.
+1. That's where I'm headed. The only reason to leave some "skipping"
for now is that it's hard (takes a bit of development time and effort)
to do the better thing, and skipping is sufficient to prevent the data
loss scenarios which is the fundamental requirement.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1038313
Received on 2009-01-20 17:31:44 CET