[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: NODE_DATA (2nd iteration)

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Tue, 13 Jul 2010 11:34:45 +0100

Having not followed any of this conversation, would it be valuable to
keep the eventual results in notes/wc-ng/ ?

On Mon, Jul 12, 2010 at 10:23 PM, Erik Huelsmann <ehuels_at_gmail.com> 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.
>
>
>  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,
>  parent_relpath  TEXT,
>  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)
>  );
>
>
> 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,
>  depth  TEXT,
>  symlink_target  TEXT,
>  properties  BLOB,
>
>  PRIMARY KEY (wc_id, local_relpath, oproot)
>  );
>
> 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.
>
> 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-07-13 12:36:29 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.