[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: Greg Stein <gstein_at_gmail.com>
Date: Tue, 13 Jul 2010 11:26:48 -0400

Erik is planning on updating the docs, once it stabilizes a little bit.

On Tue, Jul 13, 2010 at 06:34, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> 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 17:28:17 CEST

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