subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From julianf...@apache.org
Subject svn commit: r881710 - /subversion/trunk/subversion/libsvn_fs_base/notes/structure
Date Wed, 18 Nov 2009 10:04:14 GMT
Author: julianfoad
Date: Wed Nov 18 10:04:14 2009
New Revision: 881710

URL: http://svn.apache.org/viewvc?rev=881710&view=rev
Log:
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.

Modified:
    subversion/trunk/subversion/libsvn_fs_base/notes/structure

Modified: subversion/trunk/subversion/libsvn_fs_base/notes/structure
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_base/notes/structure?rev=881710&r1=881709&r2=881710&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_fs_base/notes/structure (original)
+++ subversion/trunk/subversion/libsvn_fs_base/notes/structure Wed Nov 18 10:04:14 2009
@@ -101,7 +101,7 @@
 
 
 
-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 @@
 
 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 @@
    * 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,19 @@
 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-INFO [EDIT-DATA-KEY])
+
+where
+
+    DATA-INFO ::= DATA-KEY | (DATA-KEY DATA-KEY-UNIQID)
 
-where DATA-KEY identifies the representation for the file's current
+and 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 +267,17 @@
 
 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 +290,10 @@
 KIND-SPECIFIC varies considerably depending on the kind of
 representation.  Here are the two forms currently recognized:
 
-   (("fulltext" TXN CHECKSUM) KEY)
-       The data is at KEY in the `strings' table.
+   (("fulltext" TXN [MD5 [SHA1]]) STRING-KEY)
+       The data is at STRING-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 +492,7 @@
    * 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 +585,12 @@
 
 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 +611,17 @@
 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 +933,7 @@
               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 ;
 
 



Mime
View raw message