On Wed, May 4, 2011 at 12:37, Philip Martin <philip.mar...@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
