Re: fourth tree: "INHERITED"

Greg Stein <gstein_at_gmail.com> writes:

> On Tue, Apr 13, 2010 at 06:45, Philip Martin <philip.martin_at_wandisco.com> wrote:
>> Greg Stein <gstein_at_gmail.com> writes:
>>
>> I think NODE_DATA needs more or less everything that is in the current
>> WORKING_NODE.  When a layer is reverted to uncover the layer below all
>> the old columns need to be available.  As far as I can see we need to
>> remove the WORKING_NODE tree and replace it with the NODE_DATA tree,
>> or to put it another way we need to add the op_depth column to
>> WORKING_NODE.
>
> I don't think so.
>
> As you note layer, operations on a node cannot be layered/stacked. You
> can modify the operation at a node, but you can't layer over it.
> Columns like copyfrom_* and moved_* are about the operation, rather
> than the node's data. It says *how* the node got there, rather than
> talk about the node itself.

I'm confused by the copy of a mixed revision working copy, say a
directory a revision N and a file at revision N+1. We need a working
node for the directory, to store N, and a working node for the file,
to store N+1. Now delete the copied file and replace with something
else, that overwrites the N+1 in the working node. Now reverting the
replace cannot restore the original copy since the N+1 is gone, so
what does the copied file look like, revision N? I suppose that is
acceptable, the original copy, prior to the replace, was not a simple
copy. We could argue that the copy of a mixed revision working copy
is already a bunch of roots. Suppose I delete the copied file at N+1
and then revert. Does it go back to N+1 or N?

> The BASE_NODE table is "what", now "how", so it more closely resembles
> the suggested NODE_DATA table.
>
>>> Those columns, plus the key, may be about it. I don't know that this
>>> table needs a presence column, as the "visible" state is determined by
>>> the BASE and WORKING trees. This is why I suggest that maybe we're
>>> looking more at how to represent (in the database) the WORKING tree,
>>> than truly adding a new "tree".
>>
>> One thing that occurs to me is that this layering always occurs on
>> deleted children of copied parents, it never occurs on roots of
>> operations (be they adds, deletes, copies or moves).
>
> I can copy/move subtrees into another copied-subtree without
> replacement. But you're right: all the resulting nodes are disjoint.
> No true layering occurs.
>
>>  Roots can never
>> lie one on top of the other.  I wonder if we should make WORKING_NODE
>> only hold roots, and have a different node type for children.  The
>> child node would not need the columns that are inherited from the
>> parent,
>
> That is how NODE_DATA is defined :-) ... the WORKING_NODE table just
> defines operations and all the data for the nodes lives over in
> NODE_DATA.

The two ideas are probably closer than I realised :)

So if I copy a directory with children is there a working node for
each child?

-- 
Philip