On Wed, May 4, 2011 at 12:37, Philip Martin <philip.martin_at_wandisco.com> wrote:
> To make the new single-txn delete pass the regression tests I had to
> make it leave ACTUAL_NODE rows with tree conflicts. This preserved the
> behaviour of the old per-node delete code, but I'm wondering if that is
> the correct thing to do. I suspect that the current behaviour is, in
> part at least, accidental--I think is stems from the time when tree
> conflicts were stored on the parent node and so deleting a conflicted
> node would leave the tree conflict unless the parent node was also
> modified.
>
> The current behaviour is that if I have a node in conflict:
>
> $ svn st wc
> R C wc/A/f
> > local add, incoming add upon update
> Summary of conflicts:
> Tree conflicts: 1
>
> and I delete the conflicted node:
>
> $ svn rm --force wc/A/f
> D wc/A/f
>
> it remains in conflict:
>
> $ svn st wc
> D C wc/A/f
> > local add, incoming add upon update
> Summary of conflicts:
> Tree conflicts: 1
>
> I'd like to change this so that delete removes the ACTUAL_NODE row and
> thus automatically resolves the conflict.
>
> Anybody see any problems that would arise?
I think the conflict should turn into "local delete, incoming add upon update".
> It also solves one of the orphaned ACTUAL_NODE problems: if the
> conflicted node is within an added tree then deleting the tree and
> leaving the ACTUAL_NODE row could result in an ACTUAL_NODE that has no
> parents.
That would still be a "local delete, incoming add upon update". Not
sure whether that would be located at the child, or at the deleted
ancestor. The update editor has a notion of conflicted parents, and
this seems to follow that case.
Cheers,
-g
Received on 2011-05-04 18:42:49 CEST