Pish, only the OpenOffice attachment was preserved. Here's a PDF copy, temporarily: <http://filebin.ca/fobqtm/nodes-states-2.pdf>.
- Julian On Tue, 2010-09-21 at 18:41 +0100, Julian Foad wrote: > 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 >
