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
>
Received on 2010-09-21 20:05:58 CEST