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.
