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:
>...
>> FULL SET OF VALUES
>>
>> 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
deleted.
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?
Cheers,
-g
Received on 2010-09-20 21:36:55 CEST