On Thu, Sep 2, 2010 at 18:39, Julian Foad <julian.foad_at_wandisco.com> wrote:
>> Comments? Fears? Enhancements?
> It would be useful if you could post the latest version of the
> description of the new format. Here's a bit of introductory text I
> wrote, starting with a paragraph of yours from wc-metadata.sql:
> /* The NODE_DATA table describes the way working nodes are layered on top of
> base nodes and on top of other working nodes, due to nested tree structure
> changes. The layers are modelled using the "op_depth" column.
> An "operation depth" refers to the number of directory levels down from
> the WC root at which a tree-change operation (delete, add, copy, move,
> replace) was performed. It does NOT refer to the number of path
There is no "replace" operation. There are deletes and then an add/copy/move.
> As for the three columns holding cached values, it seems a bit impure
> but pragmatically OK to move them into NODES, and certainly it would be
> unhelpful to keep the existing BASE_NODE and WORKING_NODE tables with
> their present names and only those columns in them.
translated_size and last_mod_time would nominally go into ACTUAL_NODE.
Hyrum and I decided against that, however, because it meant we would
have to always create ACTUAL_NODE rows. With the values in *_NODE, we
can defer creating rows in ACTUAL_NODE until something comes up.
> We need to describe how the layering works for copies, deletes, and
> adds. In particular I'm recalling something about how local adds aren't
> recursive, unlike copies, so an additional change within an added dir
> doesn't work the same way with regard to op_depth as it would inside a
> copied dir.
Adds within other adds don't layer. You're simply adding more nodes at
the parent's op_depth.
Deleting an ancestor of a deleted node also does not create an
additional layer. Instead, we establish the new op_depth and relabel
all of the deleted children with that new op_depth so that it looks
like one big happy delete operation.
Copies/moves always introduce a new layer.
Received on 2010-09-03 01:14:34 CEST