On Wed, 2011-05-04 at 12:42 -0400, Greg Stein wrote: > 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?
Yes, I do. A tree conflict should remain marked until the user declares it resolved. The user should be able to review the conflicts that were raised, make a series of local modifications, review again the conflicts that were originally raised, and then mark them as resolved when the user is ready to do so. > I think the conflict should turn into "local delete, incoming add upon > update". No, it should not change. Your suggestion would mean "an incoming add conflicted with the local delete", which is not true. The "local" information provided here should not be a duplicate of the node's current status; it should simply show what local change conflicted with the incoming change. > > 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. I can't see how the no-parents thing could happen, because there would be a tree conflict only at the root-most parent that conflicts. - Julian
