[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: add NODES.prior_deleted boolean column

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 22 Sep 2010 18:27:26 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.