Greg Stein wrote: > After working through the several email messages, and discussion, I > believe we're now down to a simple change: > > * add a "prior_deleted" flag to NODES > > The flag simply means that a node exists prior to this layer and has > been deleted or moved-away. The 'presence' column may say the same > thing, but it might also describe data that is replacing the > deletion/move.
Do you see this working in conjunction with the current set of presence
values, or your proposed extended set?
That flag would just mean "There is a row for the same path with a
smaller op_depth and with a non-negative kind of presence", right? So
whether we actually store that flag is a matter of impl/efficiency, not
of logical design. Have I understood?
The subject that this arose from was how to store all the possible
states of a working row. First I want to know what are all the possible
states of a working row that we need to represent, before we decide how
to represent them. I don't think we have ever written them down yet, in
full detail, so I have tried.
Please see the two tables in the "nodes-states" document that I am
attaching as .ods and as .pdf, and as two .png images. I'm not sure
whether any of the attachments will get through to the list.
Table 1
The first table enumerates all the states of a row in NODES,ignoring any
"prior-deleted" or "moved-away" part of the state if the node has also
been replaced. It shows whether each such state can exist in BASE
(op_depth = 0) and/or in WORKING (op_depth > 0) rows.
The remaining columns are works in progress. The "Can be excluded?"
column starts to address the question "Can we copy or move a tree that
contains an excluded node?"
Table 2
The second table starts to define the state that results from applying
any possible structural change to a node.
I assume this is in conjunction with the current set of presence values,
not your proposed extended set. So the possible changes would be
encoded as:
> When a deletion (of a subtree) occurs, then we create a new layer at
> <relpath, op_depth>. New rows are written for the root, and all
> children, using that op_depth value. If this is a moved-away, then we
> store the destination into moved_to at the root *only* (which can then
> later discriminate between the two types of deletions; children need
> to look to the root to discriminate; I bet this need is rare). Note
> that the deletion process needs to look for mods to descendents:
> deletes are integrated into this one; other operations may error with
> "can't delete local mods" or somesuch.
>
> For the following actions, these are applied to the root of a deletion:
What do you mean "these are applied to the root of a deletion"? I guess
"add", "copy-here", "move-here" can only be applied to the root of a
deletion or to an unversioned/not-present path; is that it?
> If an add occurs, then the root is updated to set presence='added'. No
> other changes are needed.
Apart from setting the new node kind. And apart from changing the
op_depth of all its still-deleted children to obey the deletion-op-depth
rule:
checkout: (A/B, A/B/C, A/B/gamma),op_d=0,normal
delete A/B: add rows (A/B, A/B/C, A/B/gamma),op_d=2,deleted
add new file B: modify row (A/B),op_d=2:
presence/status := deleted+added
kind := file
modify rows (A/B/C, A/B/gamma),op_d=2:
op_d := 3
- Julian
> If a copied-here or moved-here occurs, then the root is updated with
> the appropriate status and source information. Child nodes *may* have
> their presence switched from 'deleted' to 'copied-here' or
> 'moved-here' (depends on whether the arriving nodes intersect with the
> old namespace). New nodes may be introduced, with presence=$whatever
> and prior_deleted=0 (FALSE)
>
> If a deletion of a child (subtree) of copied-here or moved-here
> occurs, then it has a new op_depth and defines a whole new layer. The
> "prior_deleted" is set to 1 (TRUE) indicating the prior layer (which
> happens to be the copy/move-here) has been deleted.
>
> Deletion of an add is effectively a revert. If this is a child, then
> the layer is simply removed (it only has one node). If the
> deletion/revert of an add has prior_deleted=1 (meaning it is a root),
> then the node is rewritten to presence='deleted', restoring it to the
> state when the deletion first occurred. (and yes, a second revert
> undoes the deletion, etc...).
>
> Reverting a child of a moved/copied-here tree is invalid. When you
> revert the root, then the children at this op_depth are traversed: any
> nodes with prior_deleted=1 are restored to presence=deleted, and nodes
> with prior_deleted=0 (newly-arrived from the copy/move) are simply
> removed.
>
> Note that prior_deleted is set to TRUE only for a deletion operation
> (when presence is set to 'deleted'). That implies a prior node
> existed. For the sequence [rm A/B, add A/B, add A/B/foo], the node
> A/B/foo will have op_depth=3 and prior_deleted=0 since the row was
> created by an add. Assuming that A/B/foo existed originally, then
> prior_deleted=1 at <A/B/foo, op_depth=2>.
>
>
> I think that is it. Summarized a bit better from the earlier thread.
>
> Cheers,
> -g
nodes-states-2.ods
Description: application/vnd.oasis.opendocument.spreadsheet
