[Zodb-checkins] CVS: ZODB3/ZODB/FileStorage - FileStorage.py:1.1.2.3

[Jeremy Hylton]

Update of /cvs-repository/ZODB3/ZODB/FileStorage
In directory cvs.zope.org:/tmp/cvs-serv16923

Modified Files:
      Tag: ZODB3-mvcc-2-branch
	FileStorage.py 
Log Message:
Remove format comments and add simple doc string.

The format comments are in format.py.


=== ZODB3/ZODB/FileStorage/FileStorage.py 1.1.2.2 => 1.1.2.3 ===
--- ZODB3/ZODB/FileStorage/FileStorage.py:1.1.2.2	Thu Oct  9 16:26:23 2003
+++ ZODB3/ZODB/FileStorage/FileStorage.py	Thu Oct 30 15:38:01 2003
@@ -11,111 +11,10 @@
 # FOR A PARTICULAR PURPOSE
 #
 ##############################################################################
-#
-#  File-based ZODB storage
-#
-# Files are arranged as follows.
-#
-#   - The first 4 bytes are a file identifier.
-#
-#   - The rest of the file consists of a sequence of transaction
-#     "records".
-#
-# A transaction record consists of:
-#
-#   - 8-byte transaction id, which is also a time stamp.
-#
-#   - 8-byte transaction record length - 8.
-#
-#   - 1-byte status code
-#
-#   - 2-byte length of user name
-#
-#   - 2-byte length of description
-#
-#   - 2-byte length of extension attributes
-#
-#   -   user name
-#
-#   -   description
-#
-#   -   extension attributes
-#
-#   * A sequence of data records
-#
-#   - 8-byte redundant transaction length -8
-#
-# A data record consists of
-#
-#   - 8-byte oid.
-#
-#   - 8-byte serial, which is a type stamp that matches the
-#     transaction timestamp.
-#
-#   - 8-byte previous-record file-position.
-#
-#   - 8-byte beginning of transaction record file position.
-#
-#   - 2-byte version length
-#
-#   - 8-byte data length
-#
-#   ? 8-byte position of non-version data
-#     (if version length > 0)
-#
-#   ? 8-byte position of previous record in this version
-#     (if version length > 0)
-#
-#   ?   version string
-#     (if version length > 0)
-#
-#   ?   data
-#     (data length > 0)
-#
-#   ? 8-byte position of data record containing data
-#     (data length == 0)
-#
-# Note that the lengths and positions are all big-endian.
-# Also, the object ids time stamps are big-endian, so comparisons
-# are meaningful.
-#
-# Version handling
-#
-#   There isn't a separate store for versions.  Each record has a
-#   version field, indicating what version it is in.  The records in a
-#   version form a linked list.  Each record that has a non-empty
-#   version string has a pointer to the previous record in the version.
-#   Version back pointers are retained *even* when versions are
-#   committed or aborted or when transactions are undone.
-#
-#   There is a notion of "current" version records, which are the
-#   records in a version that are the current records for their
-#   respective objects.  When a version is comitted, the current records
-#   are committed to the destination version.  When a version is
-#   aborted, the current records are aborted.
-#
-#   When committing or aborting, we search backward through the linked
-#   list until we find a record for an object that does not have a
-#   current record in the version.  If we find a record for which the
-#   non-version pointer is the same as the previous pointer, then we
-#   forget that the corresponding object had a current record in the
-#   version. This strategy allows us to avoid searching backward through
-#   previously committed or aborted version records.
-#
-#   Of course, we ignore records in undone transactions when committing
-#   or aborting.
-#
-# Backpointers
-#
-#   When we commit or abort a version, we don't copy (or delete)
-#   and data.  Instead, we write records with back pointers.
-#
-#   A version record *never* has a back pointer to a non-version
-#   record, because we never abort to a version.  A non-version record
-#   may have a back pointer to a version record or to a non-version
-#   record.
-#
-__version__='$Revision$'[11:-2]
+"""Storage implementation using a log written to a single file.
+
+$Revision$
+"""
 
 import base64
 from cPickle import Pickler, Unpickler, loads