[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Making delete resolve tree conflicts

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Wed, 04 May 2011 18:18:15 +0100

Greg Stein <gstein_at_gmail.com> writes:

> 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".

I suppose that would make the conflict more accurate, but is it better
than simply resolving the conflict?

>> 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.

Again, is that better than resolving the conflict?

We would have to move the conflict, the wc code barely handles
actual-only nodes, I expect if will do even worse on actual-only nodes
that don't have parents.

Received on 2011-05-04 19:20:00 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.