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

Re: Making delete resolve tree conflicts

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 5 May 2011 15:03:56 -0400

On Thu, May 5, 2011 at 10:58, Julian Foad <julian.foad_at_wandisco.com> wrote:
> On Thu, 2011-05-05 at 14:48 +0100, Philip Martin wrote:
>>   - fail, with an error about the orphaned conflict
> Doesn't feel right.  The high-level "svn delete" operation is welcome to
> fail if there are any unresolved conflicts, like it does when there are
> local modifications (unless "--force" is given), but if at all possible
> this low-level operation should be designed so as not to fail on such
> things.

This seems right. The user has not handled a conflict. We don't allow
a number of operations when there are outstanding conflicts. Simply
letting the user toss out the information without a resolution does
not seem right.

iirc, update will skip a node that is in a conflicted state. In the
same way, a delete would do the same, but... you can't delete the
parent if you've skipped a child. Thus, I think the delete should

High or low level... the wc_db API allows you to do a lot of monkeying
around. So yeah, I don't think it needs to enforce this level of
semantics. That should be at the svn_wc_delete() level.

>>   - delete all conflicts
>> I still favour making delete remove all tree conflicts.  It's both easy
>> to implement and easy to explain.  It's also what happens with text and
>> property conflicts.
> I have to admit that simply deleting all conflicts seems like a nice
> simple approach.  Simple in conceptual behaviour, I mean, and if it's
> simple to implement too that's a bonus.

wc_db could do this, as long as we put a check for conflicts up in
svn_wc_delete() to look for unresolved conflicts.

Received on 2011-05-05 21:04:23 CEST

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.