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

Re: [PATCH] NODES table presence values

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 20 Sep 2010 15:36:17 -0400

On Mon, Sep 20, 2010 at 14:07, Julian Foad <julian.foad_at_wandisco.com> wrote:
> On Mon, 2010-09-20 at 18:45 +0100, Julian Foad wrote:
>> The values listed above cover most of the cases.  Next we must consider
>> how to get a full set of values to represent all possible changes.
>> The possible changes to an unoccupied path are:
>>   added
>>   copied-here (as root or as child of op)
>>   moved-here  (as root or as child of op)
>> and the possible changes to an occupied path are:
>>    [
>>     delete
>>     moved-away (as root or as child of op)
>>    ]
>>   x
>>    [
>>     <no replacement>
>>     added
>>     copied-here (as root or as child of op)
>>     moved-here  (as root or as child of op)
>>    ]
>> Are you planning to encode all these combinations as separate values?
>> That's 11 in total, plus whatever valid combinations that involve
>> excluded/absent/file-external.
> >From IRC:
> <julianf> ehu: Re. deletes: I think you're feeling, and I feel as well a
> bit, that "delete" and "move-away" are really operations on the layer
> below and thus should be indicated within the layer below: there is no
> perhaps need to create a new row because there is no repos-node-id or
> node-kind or other node information to store about a delete or
> move-away. The only info there is ... the fact that it's del or mv-away,
> and (possibly) this (not really well defined) moved_to path.
> <ehu> yes.
>  that's my feeling.
>  I understand the choices with respect to where we are today.
>  but the question is if the single presence value in the top-level layer
> really does what it needs to, now that we're moving to a multi-layer
> model.
> <julianf> ehu: So maybe it makes sense to swap the layering of the
> "creation" part of a NODES row and the "deletion" part of a row. Let the
> "creation" part be considered as the lower half of the layer, and then a
> possible "deleted/moved-to-PATH" indication to be considered as an
> operation "above" the creation (in the sense of "nearer to the user's
> working version").

Erik and I talked further on IRC...

I believe the right approach is a simple boolean "prior-deleted",
meaning "the nodes visible just under *this* layer have been deleted".
Examining the root node's moved_to column can refine how the subtree
was deleted/moved-away.

I dislike the concept of modifying prior layers (preferring to see
them as inviolate/readonly until I revert recent layers). If I say
"delete", then it should be a new layer describing which nodes got

Several more things came up in conversation:

* a simple rule for "is this revertable?" is "does the node's op_depth
match its path component count?"
* adds have variant op_depth values in a subtree. thus, each node is
revertable (and implicitly reverting its subtree)
* deletes have a single op_depth value, making only the root
revertable. when deleting a node, all previously-deleted children will
need their op_depth updated

And I identified one more problem here [in discussion with Erik now]:

* svn mv A B ; svn add A ; svn add A/foo

The op_depth of A and A/foo (assuming the latter existed in the
original A) has the value 1. After the adds, A has 1, and A/foo has 2.
Thus, we lose the op_depth defined for the move. We can certainly scan
upwards to find that root (tho we've been wanting to skip these kinds
of scans).

Any thoughts?

Received on 2010-09-20 21:36:55 CEST

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