Hi Erik.
Would you or anybody volunteer to draw a diagram of how these table rows
look in various simple-ish WC states?
I feel stupid saying this, but I haven't yet got much of an idea at all
about how a set of database rows will represent a particular collection
of repository nodes and local changes in the new scheme. I know roughly
what the aim is (to be able to represent nested tree changes more
flexibly), and I can read what elements of data will be stored in each
table, but I am missing the part that says how those are connected.
At this point we might as well assume it's a single DB - I think that
will be clearest.
Thanks.
- Julian
On Mon, 2010-07-12 at 23:23 +0200, Erik Huelsmann 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-08-02 21:06:15 CEST