Update to <libsvn_fs_base/notes/structure> attached - any review
comments before I commit?
I'm attempting to update the documentation of the BDB schema (as in
v1.6, to begin with), and to draw it in a diagram. Current attempt at
<http://imagebin.ca/img/uoTQ0U.png>.
I got the idea and style from
<http://homepages.paradise.net.nz/~ejrh/subversion/mysql/>. Aim is to be
able to show precisely what changes I need for Obliterate.
(I'm targeting FSFS but BDB seems better documented, so I'll look at the
schema for BDB and then translate to FSFS. That's my thought. Crazy?)
- Julian
Update the BDB schema documentation to reflect changes that have been made
between Subversion 1.0 and 1.6.
* subversion/libsvn_fs_base/notes/structure
Several updates and clarifications.
--This line, and those below, will be ignored--
Index: subversion/libsvn_fs_base/notes/structure
===================================================================
--- subversion/libsvn_fs_base/notes/structure (revision 880857)
+++ subversion/libsvn_fs_base/notes/structure (working copy)
@@ -101,7 +101,7 @@ structure summary" section of this docum
-NODE-REVISION and HEADER: how we represent a node revision
+NODE-REVISION: how we represent a node revision
We represent a given revision of a file or directory node using a list
skel (see skel.h for an explanation of skels). A node revision skel
@@ -116,7 +116,7 @@ on what kind of node this is --- file, d
HEADER has the form:
- (KIND CREATED-PATH PRED-ID PRED-COUNT)
+ (KIND CREATED-PATH PRED-ID PRED-COUNT HAS-MERGEINFO MERGEINFO-COUNT)
where:
@@ -134,6 +134,9 @@ where:
* PRED-COUNT, if present, indicates the number of predecessors the
node revision has (recursively).
+ * HAS-MERGEINFO and MERGEINFO-COUNT, if present, indicate ...
+ ### TODO
+
Note that a node cannot change its kind from one revision to the next.
A directory node is always a directory; a file node is always a file;
etc. The fact that the node's kind is stored in each node revision,
@@ -164,12 +167,15 @@ FILE: how files are represented.
If a NODE-REVISION's header's KIND is "file", then the node-revision
skel represents a file, and has the form:
- (HEADER PROP-KEY DATA-KEY [EDIT-DATA-KEY])
+ (HEADER PROP-KEY DATA-KEY [DATA-KEY-UNIQID] [EDIT-DATA-KEY])
where DATA-KEY identifies the representation for the file's current
contents, and EDIT-DATA-KEY identifies the representation currently
available for receiving new contents for the file.
+DATA-KEY-UNIQID ...
+### TODO
+
See discussion of representations later.
@@ -257,15 +263,17 @@ and parse it appropriately. A represent
where HEADER is
- (KIND TXN [CHECKSUM])
+ (KIND TXN [MD5 [SHA1]])
The KIND is "fulltext" or "delta". TXN is the txn ID for the txn in
-which this representation was created. CHECKSUM is a checksum of the
+which this representation was created. MD5 is a checksum of the
representation's contents, that is, what the representation produces,
regardless of whether it is stored deltified or as fulltext. (For
-compatibility with older versions of Subversion, CHECKSUM may be
+compatibility with older versions of Subversion, MD5 may be
absent, in which case the filesystem behaves as though the checksum is
-there and is correct.)
+there and is correct.) An additional kind of checksum, SHA1, is present
+in newer formats, starting with version ...
+### TODO
The TXN also serves as a kind of mutability flag: if txn T tries to
change a representation's contents, but the rep's TXN is not T, then
@@ -278,10 +286,10 @@ count as a change, since that wouldn't a
KIND-SPECIFIC varies considerably depending on the kind of
representation. Here are the two forms currently recognized:
- (("fulltext" TXN CHECKSUM) KEY)
+ (("fulltext" TXN [MD5 [SHA1]]) KEY)
The data is at KEY in the `strings' table.
- (("delta" TXN CHECKSUM) (OFFSET WINDOW) ...)
+ (("delta" TXN [MD5 [SHA1]]) (OFFSET WINDOW) ...)
Each OFFSET indicates the point in the fulltext that this
element reconstructs, and WINDOW says how to reconstruct it:
@@ -480,7 +488,7 @@ where:
* ROOT-ID is the node revision ID of the committed transaction's (or
revision's) root node.
- * REVISION represents the revision that was created when the
+ * REV represents the revision that was created when the
transaction was committed.
* PROPLIST is a skel giving the revision properties for the
@@ -573,6 +581,12 @@ following forms:
where:
+ * "copy" indicates an explicitly requested copy, and "soft-copy"
+ indicates a node that was cloned internally as part of an
+ explicitly requested copy of some parent directory. See the
+ section "Copies and Copy IDs" in the file <fs-history> for
+ details.
+
* SRC-PATH and SRC-TXN are the canonicalized absolute path and
transaction ID, respectively, of the source of the copy.
@@ -593,17 +607,17 @@ Locks
When a caller locks a file -- reserving an exclusive right to modify
or delete it -- an lock object is created in a `locks' table.
-The `locks' table is a btree whose key is a UUID string (also known as
-a "lock-token"), and whose value is a skel representing a lock. The
+The `locks' table is a btree whose key is a UUID string known as
+a "lock-token", and whose value is a skel representing a lock. The
fields in the skel mirror those of an svn_lock__t (see svn_types.h):
- ("lock" PATH UUID OWNER COMMENT XML-P CREATION-DATE EXPIRATION-DATE)
+ ("lock" PATH TOKEN OWNER COMMENT XML-P CREATION-DATE EXPIRATION-DATE)
where:
* PATH is the absolute filesystem path reserved by the lock.
- * UUID is the universally unique identifier of the lock, also known
+ * TOKEN is the universally unique identifier of the lock, known
as the lock-token. This is the same as the row's key.
* OWNER is the authenticated username that "owns" the lock.
@@ -915,7 +929,7 @@ Copies:
REAL-COPY ::= ("copy" SRC-PATH SRC-TXN DST-NODE-ID)
SOFT-COPY ::= ("soft-copy" SRC-PATH SRC-TXN DST-NODE-ID)
SRC-PATH ::= atom ;
- SRC-REV ::= TXN ;
+ SRC-TXN ::= TXN ;
DST-NODE-ID ::= NODE-REV-ID ;
