[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: wc-metadata.sql3

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 19 Sep 2008 15:42:15 +0300 (Jerusalem Daylight Time)

Some comments on the WC SQL schema (r33179:r33180):

> /* ### the following tables define the BASE tree */
>
> CREATE TABLE REPOSITORY (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> /* the UUID of the repository */
> uuid TEXT NOT NULL,
>
> /* URL of the root of the repository */
> url TEXT NOT NULL
> );
>
> CREATE INDEX I_UUID ON REPOSITORY (uuid);
>
>
> CREATE TABLE WORKING_COPY (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> /* foreign key to REPOSITORY.id */
> repos_id INTEGER NOT NULL,
>
> /* absolute path in the local filesystem */
> local_path TEXT NOT NULL,
>

Why NOT NULL? local_path is only needed when the metadata is stored outside
the wc.

> /* repository path corresponding to root of the working copy */
> repos_path TEXT NOT NULL
> );
>
> CREATE UNIQUE INDEX I_LOCAL_PATH ON WORKING_COPY (local_path);
>
>
> CREATE TABLE DIRECTORY (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> wc_id INTEGER NOT NULL,
>
> /* relative path from wcroot */
> local_relpath TEXT NOT NULL,
>
> /* path in repository */
> /* ### for switched subdirs, this could point to something other than
> ### local_relpath would imply. anything else for switching? */
> repos_path TEXT NOT NULL

For non-switched directories, repos_path can be derived from local_relpath.
And non-switched is the more common case. Storing repos_path always (it is
NOT NULL) seems slightly redundant.

(Also, what does switched mean here? Switched relative to the parent, or
relative to the wc root?)

> );
>
> CREATE UNIQUE INDEX I_DIR_PATH ON DIRECTORY (wc_id, local_relpath);
>
>
> CREATE TABLE NODE (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> dir_id INTEGER NOT NULL,
>

What is dir_id of the wc root dir?

> filename TEXT,
>

filename NOT NULL? The empty string can represent the "this dir" entry
(is there another reason NULL are allowed?).

> revnum INTEGER NOT NULL,
>
> kind INTEGER NOT NULL,
>
> text_id INTEGER,
>
> /* ### NOT NULL? do we always have this info? */
> changed_rev INTEGER,
> /* ### or use TEXT and ISO-8601 datetime? */
> changed_date INTEGER,

What is the precision of this INTEGER? Days? Seconds? Microseconds?

> changed_author TEXT,
>
> /* ### the following fields are used to define the WORKING tree */
> conflict_old TEXT,
> conflict_new TEXT,
> conflict_working TEXT,
> prop_reject TEXT, /* ### is this right? */
>
> /* ### note: these are caches from the server! */
> lock_token TEXT,
> lock_owner TEXT,
> lock_comment TEXT,
> lock_date INTEGER, /* ### or TEXT and ISO? */
>

Same question.

>
> /* ### some text or prop changes exist. this node is in a changelist. */
           ^ ^

One of these two sentences doesn't belong here?

> changelist_id INTEGER
> );
>
> CREATE UNIQUE INDEX I_PATH ON NODE (dir_id, filename);
> CREATE INDEX I_NODELIST ON NODE (dir_id);
> CREATE INDEX I_LOCKS ON NODE (lock_token);
>
>
> CREATE TABLE PROPERTIES (
> node_id INTEGER NOT NULL,
>
> name TEXT NOT NULL,
>
> value BLOB NOT NULL,
>
> PRIMARY KEY (node_id, name)
> );
>
> CREATE UNIQUE INDEX I_NODE_PROPS ON PROPERTIES (node_id);
>
>
> CREATE TABLE BASE_TEXT (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> checksum TEXT NOT NULL,
>

Checksum kind? (corresponds to the 'kind' field of svn_checksum_t)

> compression INTEGER NOT NULL,
>
> /* ### do we need to deal with repos-size vs. eol-style-size? this
> ### size should be what is in ACTUAL so we can quickly detect
> ### differences. */

s/should be what is/is what should be/ ?

> actual_size INTEGER NOT NULL,
>
> /* ### used to verify the pristine file is "proper" */
> stored_size INTEGER NOT NULL,
>
> refcount INTEGER NOT NULL
> );
>
> CREATE UNIQUE INDEX I_CHECKSUM ON BASE_TEXT (checksum);
>
> /* ------------------------------------------------------------------------- */
>
> /* ### the following tables define the WORKING tree */
>
> /* ### add/delete nodes */
> CREATE TABLE NODE_CHANGES (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> dir_id INTEGER NOT NULL,
>
> filename TEXT,
>
> /* ### NULL kind implies "deletion". or use a special enumerated value? */
> kind INTEGER,
>
> copyfrom_repos_path TEXT,
> copyfrom_revnum INTEGER,
>
> changelist_id INTEGER
> );
>
> CREATE UNIQUE INDEX I_PATH_CHANGES ON NODE_CHANGES (dir_id, filename);
> CREATE INDEX I_NODELIST_CHANGES ON NODE_CHANGES (dir_id);
>
>

> CREATE TABLE PROPERTIES_NEW (
> node_changes_id INTEGER NOT NULL,
>
> name TEXT NOT NULL,
>
> value BLOB NOT NULL,
>
> PRIMARY KEY (node_changes_id, name)
> );
>
> CREATE UNIQUE INDEX I_NEW_NODE_PROPS ON PROPERTIES_NEW (node_changes_id);
>
>
> CREATE TABLE PROPERTIES_EDIT (
> node_id INTEGER NOT NULL,
>
> name TEXT NOT NULL,
>
> /* ### NULL implies deletion. */
> value BLOB,
>
> PRIMARY KEY (node_id, name)
> );
>
> CREATE UNIQUE INDEX I_EDIT_NODE_PROPS ON PROPERTIES_EDIT (node_id);
>

Repeating what was discussed on IRC:

    CREATE TABLE PROPERTIES_WORKING (
      dir_id INTEGER NOT NULL,
    
      /* ### scheduled-delete files don't have prop changes! */
      filename TEXT NOT NULL,
    
      /* propname */
      name TEXT NOT NULL,
    
      /* ### NULL implies deletion. */
      value BLOB,
    
      PRIMARY KEY (dir_id, filename, name)
      );
    
    CREATE UNIQUE INDEX I_WORKING_PROPS ON PROPERTIES_WORKING (dir_id, filename);

>
> CREATE TABLE CHANGELIST (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> wc_id INTEGER NOT NULL,
>
> name TEXT NOT NULL
> );
>
> CREATE UNIQUE INDEX I_CHANGELIST ON CHANGELIST (wc_id, name);
> CREATE UNIQUE INDEX I_CL_LIST ON CHANGELIST (wc_id);

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-19 14:42:36 CEST

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