On Wed, 2011-05-04 at 12:42 -0400, Greg Stein wrote:
> 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?
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
Received on 2011-05-04 19:22:01 CEST