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-12 23:23:43 CEST