On Thu, 2011-05-05 at 14:48 +0100, Philip Martin wrote: > Philip Martin <philip.mar...@wandisco.com> writes: > > > svnadmin create repo > > svn mkdir -mm file://`pwd`/repo/A > > svn co -r0 file://`pwd`/repo wc > > svn mkdir --parents wc/X/Y/A > > svn merge -c1 ^/ wc/X/Y > > svn rm --force wc/X > > > > sqlite3 wc/.svn/wc.db "select op_depth, local_relpath from nodes" > > 0| > > > > sqlite3 wc/.svn/wc.db "select local_relpath from actual_node" > > X/Y/A > > After discussion on IRC i think we agree that leaving an "orphaned" > actual-node for X/Y/A is wrong. So how should svn_wc__db_op_delete > behave? It could: > > - delete the orphaned conflict but leave any non-orphaned conflicts
This is probably the option that most closely mirrors 1.6.x operation. In 1.6.x, a tree conflict would remain if the parent directory remained (or something like that). I thought that behaviour was entirely intentional but now I'm not so sure. > - move the orphaned conflict to some non-orphaned row You mean convert it into some kind of tree conflict description on a parent directory that indicates there was a conflict somewhere inside the subtree? No, I don't think that makes sense within our idea of conflicts. And if we were going to do that kind of logical transformation, it should be done by higher level code. > - 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. > - 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. - Julian
