> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: vrijdag 3 september 2010 1:14
> To: Julian Foad
> Cc: Erik Huelsmann; dev_at_subversion.apache.org
> Subject: Re: [PROPOSAL] WC-NG: merge NODE_DATA, WORKING_NODE and
> BASE_NODE into a single table (NODES)
>
> On Thu, Sep 2, 2010 at 18:39, Julian Foad <julian.foad_at_wandisco.com>
> wrote:
> >...
> >> Comments? Fears? Enhancements?
> >
> > +1.
> >
> > 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.
I'm not sure if I follow your reasoning here. (layering vs op_depths)
I think local additions should always be their own op (and have their own
op_depth). That would simplify the revert and commit process: They would
only have to do restructuring changes(add/delete) when there is a new
op_depth.
So the commit harvester would be as simple as walking the operations (for
restructuring operations) and checking present nodes for text and prop mods.
If multiple levels of adds would be a single operation, we would have to
perform more checks to see if it is an operation that must be committed (or
requires restructuring on revert), while we could just compare the op_depth
with the number of '/'-s in the local_relpath if every local add is its own
op_depth.
Bert
> Cheers,
> -g
Received on 2010-09-03 10:48:45 CEST