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
fail.
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.
Cheers,
-g
Received on 2011-05-05 21:04:23 CEST