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_wri...@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 <ehu...@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. >> >
