Greg Stein <[email protected]> writes: > On Tue, Apr 13, 2010 at 06:45, Philip Martin <[email protected]> > wrote: >> Greg Stein <[email protected]> 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
