On Tue, Sep 21, 2010 at 13:41, Julian Foad <julian.foad_at_wandisco.com> 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?
The extended set. The "current set" is dead to me.
> 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?
No. It means that this (relpath/op_depth) layer was created by a
deletion ("svn rm" or "svn mv").
Additional operations (add, copy-here, move-here) might alter this
layer, but it started with the deletion of a prior node/subtree.
> 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.
These tables are so much more complicated that it is very hard to
read/understand them. It is billowing the combinatorics of what seems
pretty darned simple.
op_depth==0 can have the following presence values: normal,
not-present, excluded, incomplete, unauthz. prior_deleted is always 0
(FALSE).
op_depth > 0 can have the following presence values: added, deleted,
copied-here, moved-here, excluded, incomplete. prior_deleted may be 0
or 1. moved_to is a discriminator between deleted and moved-away.
>...
> 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:
>
Did you omit something here?
(I got the email as you sent it directly to me; no missing
attachments; it seems like above is missing something tho)
>> 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?
Correct. You cannot add/copy-here/move-here to a descendent of the
root of a deletion -- the root is still missing, so you have no parent
for the new nodes.
>> 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
clarify as: presence=deleted. prior_deleted=TRUE.
> add new file B: modify row (A/B),op_d=2:
> presence/status := deleted+added
> kind := file
Yes.
> modify rows (A/B/C, A/B/gamma),op_d=2:
> op_d := 3
No.
The children don't have to be touched. They just hang out in their
deleted state with the same op_depth. We *never* want to modify a rows
op_depth. That is part of its primary key(!).
If you changed your operation above to: add subtree B, B/C, B/gamma,
then you would have:
1. modify <A/B, 2>: presence=added. (and kind=dir)
2. add <A/B/C, 3>: presence=added. kind=dir.
3. add <A/B/gamma, 3>: presence=added. kind=file.
The B/C and B/gamma nodes are at a higher op_depth, so they are now
visible instead of the deleted nodes.
Cheers,
-g
Received on 2010-09-23 00:28:20 CEST