On Thu, May 5, 2011 at 10:58, Julian Foad <julian.f...@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
