Any responses would be greatly appreciated.
- Julian
On Tue, 2010-08-03, Julian Foad wrote:
> On Mon, 2010-07-12, Erik Huelsmann wrote:
> > After lots of discussion regarding the way NODE_DATA/4th tree should
> > be working, I'm now ready to post a summary of the progress. In my
> > last e-mail (http://svn.haxx.se/dev/archive-2010-07/0262.shtml) I
> > stated why we need this; this post is about the conclusion of what
> > needs to happen. Also included are the first steps there.
> >
> >
> > With the advent of NODE_DATA, we distinguish node values specifically
> > related to BASE nodes, those specifically related to "current" WORKING
> > nodes and those which are to be maintained for multiple levels of
> > WORKING nodes (not only the "current" view) (the latter category is
> > most often also shared with BASE).
> >
> > The respective tables will hold the columns shown below.
> >
> >
> > -------------------------
> > TABLE WORKING_NODE (
> > wc_id INTEGER NOT NULL REFERENCES WCROOT (id),
> > local_relpath TEXT NOT NULL,
> > parent_relpath TEXT,
> > moved_here INTEGER,
> > moved_to TEXT,
> > original_repos_id INTEGER REFERENCES REPOSITORY (id),
> > original_repos_path TEXT,
> > original_revnum INTEGER,
> > translated_size INTEGER,
> > last_mod_time INTEGER, /* an APR date/time (usec since 1970) */
> > keep_local INTEGER,
> >
> > PRIMARY KEY (wc_id, local_relpath)
> > );
> >
> > CREATE INDEX I_WORKING_PARENT ON WORKING_NODE (wc_id, parent_relpath);
> > --------------------------------
> >
> > The moved_* and original_* columns are typical examples of "WORKING
> > fields only maintained for the visible WORKING nodes": the original_*
> > and moved_* fields are inherited from the operation root by all
> > children part of the operation. The operation root will be the visible
> > change on its own level, meaning it'll have rows both in the
> > WORKING_NODE and NODE_DATA tables. The fact that these columns are not
> > in the WORKING_NODE table means that tree changes are not preserved
> > accros overlapping changes. This is fully compatible with what we do
> > today: changes to higher levels destroy changes to lower levels.
> >
> > The translated_size and last_mod_time columns exist in WORKING_NODE
> > and BASE_NODE; they explicitly don't exist in NODE_DATA. The fact that
> > they exist in BASE_NODE is a bit of a hack: it's to prevent creation
> > of WORKING_NODE data for every file which has keyword expansion or eol
> > translation properties set: these columns serve only to optimize
> > working copy scanning for changes and as such only relate to the
> > visible WORKING_NODEs.
> >
>
> Can we come up with an English description of what each table will now
> represent?
>
> "The BASE_NODE table lists the existing node-revs in the repository that
> comprise the mixed-revision tree that was most recently updated/switched
> to or checked out. (The kind and content of these nodes is not here;
> see the NODE_DATA table.)"
>
> > TABLE BASE_NODE (
> > wc_id INTEGER NOT NULL REFERENCES WCROOT (id),
> > local_relpath TEXT NOT NULL,
> > repos_id INTEGER REFERENCES REPOSITORY (id),
> > repos_relpath TEXT,
>
> We need a revision number column here to go along with repos_id and
> relpath to make a valid node-rev reference, don't we?
>
> > parent_relpath TEXT,
>
> (While we're reorganising, can we move that "parent_relpath" column to
> adjacent to "local_relpath"?)
>
> > translated_size INTEGER,
> > last_mod_time INTEGER, /* an APR date/time (usec since 1970) */
> > dav_cache BLOB,
> > incomplete_children INTEGER,
> > file_external TEXT,
> >
> > PRIMARY KEY (wc_id, local_relpath)
> > );
> >
>
> "The NODE_DATA table records the kind and shallow content (props, text,
> link target) of each node in the WC. It includes both the nodes that
> comprise the currently 'visible' (or 'actual' or 'on-disk') state of the
> WC and also all nodes that are part of a copied or moved tree but
> currently shadowed by a replacement performed inside that tree.
>
> At least one row exists for each WC path, including paths with no change
> and all paths affected by a tree change (add, delete, etc.). If the
> same path is affected by multiple levels of tree change - a replacement
> inside a copied directory, for example - then multiple rows exist with
> different 'op_depth' values."
>
> > TABLE NODE_DATA (
> > wc_id INTEGER NOT NULL REFERENCES WCROOT (id),
> > local_relpath TEXT NOT NULL,
> > op_depth INTEGER NOT NULL,
> > presence TEXT NOT NULL,
> > kind TEXT NOT NULL,
> > checksum TEXT,
> > changed_rev INTEGER,
> > changed_date INTEGER, /* an APR date/time (usec since 1970) */
> > changed_author TEXT,
>
> The changed_* columns can only belong to a node-rev that exists in the
> repository. What node-rev do they belong to and why aren't they
> alongside the node-rev details?
>
> (The changed_* columns convey essentially a rev number and two of the
> rev-props associated with that revnum that can be used in keyword
> expansions. We should consider representing that information in a more
> general form, both to avoid tying the DB format to the choice of those
> two particular revprops, and to avoid the redundancy of storing these
> same data and author values N times.)
>
>
> > depth TEXT,
> > symlink_target TEXT,
> > properties BLOB,
>
> (While we're rearranging, can we group the node-content fields together:
> kind, properties, checksum, symlink_target?)
>
> > PRIMARY KEY (wc_id, local_relpath, oproot)
>
> s/oproot/op_depth/?
>
> > );
> >
> > CREATE INDEX I_NODE_WC_RELPATH ON NODE_DATA (wc_id, local_relpath);
> >
> >
> > Which leaves the NODE_DATA structure above. The op_depth column
> > contains the depth of the node - relative to the wc root - on which
> > the operation was run which caused the creation of the given NODE_DATA
> > node. In the final scheme (based on single-db), the value will be 0
> > for base and a positive integer for WORKING related data.
>
> Let's assume single-db. By the last sentence, I understand: For each
> BASE_NODE row there is a corresponding NODE_DATA row with 'op_root' = 0;
> for every node brought in by a tree operation (copy, move, add) to an
> immediate child of the WC root there is a NODE_DATA row with 'op_root' =
> 1; for every child of a child ... 2; and so on.
>
>
> - Julian
>
>
> > In order to be able to implement NODE_DATA even without having a fully
> > functional SINGLE_DB yet, a transitional node numbering scheme needs
> > to be devised. The following numbers will apply: BASE == 0,
> > WORKING-this-dir == 1, WORKING-any-immediate-child == 2.
> >
> >
> > Other transitioning related remarks:
> >
> > * Conditional-protected experimentational sections, just like with SINGLE_DB
> > * Initial implementation will simply replace the current
> > functionality of the 2 tables, from there we can work our way through
> > whatever needs doing.
> > * Am I forgetting any others?
> >
> > Bye,
> >
> > Erik.
>
>
Received on 2010-08-10 18:18:53 CEST