On Thu, 2011-05-05 at 14:48 +0100, Philip Martin wrote:
> Philip Martin <philip.martin_at_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
Received on 2011-05-05 16:59:21 CEST