Update the BDB schema documentation to reflect changes that have been madebetween 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 ;