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
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.
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?"
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
> 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
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
> 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
> 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.
Received on 2010-09-21 19:42:22 CEST