[Zodb-checkins] SVN: ZODB/trunk/ Moved to github

jim cvs-admin at zope.org
Sat Jan 5 18:57:02 UTC 2013


Log message for revision 129018:
  Moved to github

Changed:
  D   ZODB/trunk/.bzrignore
  D   ZODB/trunk/3.11.txt
  D   ZODB/trunk/CHANGES.txt
  D   ZODB/trunk/COPYING
  D   ZODB/trunk/COPYRIGHT.txt
  D   ZODB/trunk/HISTORY.txt
  D   ZODB/trunk/LICENSE.txt
  A   ZODB/trunk/MOVED_TO_GITHUB
  D   ZODB/trunk/README.txt
  D   ZODB/trunk/bootstrap.py
  D   ZODB/trunk/buildout.cfg
  D   ZODB/trunk/doc/
  D   ZODB/trunk/ez_setup.py
  D   ZODB/trunk/log.ini
  D   ZODB/trunk/release.py
  D   ZODB/trunk/setup.py
  D   ZODB/trunk/src/

-=-
Deleted: ZODB/trunk/.bzrignore
===================================================================
--- ZODB/trunk/.bzrignore	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/.bzrignore	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,7 +0,0 @@
-.installed.cfg
-bin
-build
-develop-eggs
-eggs
-parts
-*.egg-info

Deleted: ZODB/trunk/3.11.txt
===================================================================
--- ZODB/trunk/3.11.txt	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/3.11.txt	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,59 +0,0 @@
-Wish list for 3.11.
-
-These aren't promises, but things I'd like to do:
-
-- ZEO support for loading blobs via HTTP.
-
-- ZEO cache fix for loadBefore.
-
-- invalidation events.
-
-- Make DBs context manager, so in a simple script, one could do:
-
-  with ZEO.DB(someaddr) as connection:
-      do some things in a transaction. Commit and close at the end.
-
-- Persistent sets.
-
-- PxBTrees, persistent objects as keys in BTrees.
-
-  - Compare on persistent references.
-
-- Python BTrees and persistence.
-
-- JSONic read-only mode where you can read most objects for which you
-  don't have classes as long at they have the default getstate.
-  This might be as simple as using a variation of broken objects.
-
-- persistent.Object, which handles the common case of a simple object
-  that just has some data. (The moral equivalent of a JS object. :)
-
-- API to preload objects.
-
-  Say you know you're going to oterate over an array of objects, you
-  might signal that intend to use the object with something like::
-
-    for oject in objects:
-        object._p_will_use()
-
-  (I think there's an RFC for something like this.)
-
-  For most storages, _p_will_use won't have any effect, but for ZEO,
-  it could cause a load request to be sent to the server if the object
-  isn't already loaded or in the zeo cache. This way, you could have
-  lots of loads in flight at once, mitigating round-trip costs.
-
-- ZEO cache iterator, to facilitate analysis of cache contents.
-
-- Update file-storage iterator to expose file position as non-private
-  var for transactions and database records.
-
-  Expose trans size.
-
-- Update ZEO ClientStorage to block for soem short time rather than
-  error on short disconnection.
-
-- Remove silly ZEO connection backooff by default.
-
-- Rewrite ZEO connection logic using async IO rather than threads.
-

Deleted: ZODB/trunk/CHANGES.txt
===================================================================
--- ZODB/trunk/CHANGES.txt	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/CHANGES.txt	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,387 +0,0 @@
-================
- Change History
-================
-
-4.0.0a4 (2012-12-17)
-=====================
-
-- Enforced usage of bytes for '_p_serial' of persistent objects (fixes
-  compatibility with recent persistent releases).
-
-4.0.0a3 (2012-12-01)
-=====================
-
-- Fixed: An elaborate test for trvial logic corrupted module state in a
-        way that made other tests fail spuriously.
-
-4.0.0a2 (2012-11-13)
-=====================
-
-Bugs Fixed
-----------
-
-- An unneeded left-over setting in setup.py caused installation with
-  pip to fail.
-
-4.0.0a1 (2012-11-07)
-=====================
-
-New Features
-------------
-
-- The ``persistent`` and ``BTrees`` packages are now released as separate
-  distributions, on which ZODB now depends.
-
-- ZODB no longer depends on zope.event.  It now uses ZODB.event, which
-  uses zope.event if it is installed.  You can override
-  ZODB.event.notify to provide your own event handling, although
-  zope.event is recommended.
-
-- BTrees allowed object keys with insane comparison. (Comparison
-  inherited from object, which compares based on in-process address.)
-  Now BTrees raise TypeError if an attempt is made to save a key with
-  comparison inherited from object. (This doesn't apply to old-style
-  class instances.)
-
-Bugs Fixed
-----------
-
-- Ensured that the export file and index file created by ``repozo`` share
-  the same timestamp.
-
-  https://bugs.launchpad.net/zodb/+bug/993350
-
-- Pinned the ``transaction`` and ``manuel`` dependencies to Python 2.5-
-  compatible versions when installing under Python 2.5.
-
-3.10.5 (2011-11-19)
-===================
-
-Bugs Fixed
-----------
-
-- Conflict resolution failed when state included cross-database
-  persistent references with classes that couldn't be imported.
-
-3.10.4 (2011-11-17)
-===================
-
-Bugs Fixed
-----------
-
-- Conflict resolution failed when state included persistent references
-  with classes that couldn't be imported.
-
-3.10.3 (2011-04-12)
-===================
-
-Bugs Fixed
-----------
-
-- "activity monitor not updated for subconnections when connection
-  returned to pool"
-
-  https://bugs.launchpad.net/zodb/+bug/737198
-
-- "Blob temp file get's removed before it should",
-  https://bugs.launchpad.net/zodb/+bug/595378
-
-  A way this to happen is that a transaction is aborted after the
-  commit process has started. I don't know how this would happen in
-  the wild.
-
-  In 3.10.3, the ZEO tpc_abort call to the server is changed to be
-  synchronous, which should address this case. Maybe there's another
-  case.
-
-
-Performance enhancements
-------------------------
-
-- Improved ZEO client cache implementation to make it less likely to
-  evict objects that are being used.
-
-- Small (possibly negligable) reduction in CPU in ZEO storage servers
-  to service object loads and in networking code.
-
-3.10.2 (2011-02-12)
-===================
-
-Bugs Fixed
-----------
-
-- 3.10 introduced an optimization to try to address BTree conflict
-  errors arrising for basing BTree keys on object ids. The
-  optimization caused object ids allocated in aborted transactions to
-  be reused. Unfortunately, this optimzation led to some rather
-  severe failures in some applications.  The symptom is a conflict
-  error in which one of the serials mentioned is zero.  This
-  optimization has been removed.
-
-  See (for example): https://bugs.launchpad.net/zodb/+bug/665452
-
-- ZEO server transaction timeouts weren't logged as critical.
-
-  https://bugs.launchpad.net/zodb/+bug/670986
-
-3.10.1 (2010-10-27)
-===================
-
-Bugs Fixed
-----------
-
-- When a transaction rolled back a savepoint after adding objects and
-  subsequently added more objects and committed, an error could be
-  raised "ValueError: A different object already has the same oid"
-  causing the transaction to fail. Worse, this could leave a database
-  in a state where subsequent transactions in the same process would
-  fail.
-
-  https://bugs.launchpad.net/zodb/+bug/665452
-
-- Unix domain sockets didn't work for ZEO (since the addition of IPv6
-  support). https://bugs.launchpad.net/zodb/+bug/663259
-
-- Removed a missfeature that can cause performance problems when using
-  an external garbage collector with ZEO.  When objects were deleted
-  from a storage, invalidations were sent to clients. This makes no
-  sense.  It's wildly unlikely that the other connections/clients have
-  copies of the garbage.  In normal storage garbage collection, we
-  don't send invalidations. There's no reason to send them when an
-  external garbage collector is used.
-
-- ZEO client cache simulation misshandled invalidations
-  causing incorrect statistics and errors.
-
-3.10.0 (2010-10-08)
-===================
-
-New Features
-------------
-
-- There are a number of performance enhancements for ZEO storage
-  servers.
-
-- FileStorage indexes use a new format. They are saved and loaded much
-  faster and take less space. Old indexes can still be read, but new
-  indexes won't be readable by older versions of ZODB.
-
-- The API for undoing multiple transactions has changed.  To undo
-  multiple transactions in a single transaction, pass a list of
-  transaction identifiers to a database's undoMultiple method. Calling a
-  database's undo method multiple times in the same transaction now
-  raises an exception.
-
-- The ZEO protocol for undo has changed.  The only user-visible
-  consequence of this is that when ZODB 3.10 ZEO servers won't support
-  undo for older clients.
-
-- The storage API (IStorage) has been tightened. Now, storages should
-  raise a StorageTransactionError when invalid transactions are passed
-  to tpc_begin, tpc_vote, or tpc_finish.
-
-- ZEO clients (``ClientStorage`` instances) now work in forked processes,
-  including those created via ``multiprocessing.Process`` instances.
-
-- Broken objects now provide the IBroken interface.
-
-- As a convenience, you can now pass an integer port as an address to
-  the ZEO ClientStorage constructor.
-
-- As a convenience, there's a new ``client`` function in the ZEO
-  package for constructing a ClientStorage instance.  It takes the
-  same arguments as the ClientStorage constructor.
-
-- DemoStorages now accept constructor athuments, close_base_on_close
-  and close_changes_on_close, to control whether underlying storages
-  are closed when the DemoStorage is closed.
-
-  https://bugs.launchpad.net/zodb/+bug/118512
-
-- Removed the dependency on zope.proxy.
-
-- Removed support for the _p_independent mini framework, which was
-  made moot by the introduction of multi-version concurrency control
-  several years ago.
-
-- Added support for the transaction retry convenience
-  (transaction-manager attempts method) introduced in the
-  ``transaction`` 1.1.0 release.
-
-- Enhanced the database opening conveniences:
-
-  - You can now pass storage keyword arguments to ZODB.DB and
-    ZODB.connection.
-
-  - You can now pass None (rather than a storage or file name) to get
-    a database with a mapping storage.
-
-- Databases now warn when committing very large records (> 16MB).
-  This is to try to warn people of likely design mistakes.  There is a
-  new option (large_record_size/large-record-size) to control the
-  record size at which the warning is issued.
-
-- Added support for wrapper storages that transform pickle data.
-  Applications for this include compression and encryption.  An
-  example wrapper storage implementation, ZODB.tests.hexstorage, was
-  included for testing.
-
-  It is important that storage implementations not assume that
-  storages contain pickles.  Renamed IStorageDB to IStorageWrapper and
-  expanded it to provide methods for transforming and untransforming
-  data records.  Storages implementations should use these methods to
-  get pickle data from stored records.
-
-- Deprecated ZODB.interfaces.StorageStopIteration.  Storage
-  iterator implementations should just raise StopIteration, which
-  means they can now be implemented as generators.
-
-- The filestorage packer configuration option noe accepts values of
-  the form ``modname:expression``, allowing the use of packer
-  factories with options.
-
-- Added a new API that allows applications to make sure that current
-  data are read. For example, with::
-
-    self._p_jar.readCurrent(ob)
-
-  A conflict error will be raised if the version of ob read by the
-  transaction isn't current when the transaction is committed.
-
-  Normally, ZODB only assures that objects read are consistent, but not
-  necessarily up to date.  Checking whether an object is up to date is
-  important when information read from one object is used to update
-  another.
-
-  BTrees are an important case of reading one object to update
-  another.  Internal nodes are read to decide which leave notes are
-  updated when a BTree is updated.  BTrees now use this new API to
-  make sure that internal nodes are up to date on updates.
-
-- When transactions are aborted, new object ids allocated during the
-  transaction are saved and used in subsequent transactions. This can
-  help in situations where object ids are used as BTree keys and the
-  sequential allocation of object ids leads to conflict errors.
-
-- ZEO servers now support a server_status method for for getting
-  information on the number of clients, lock requests and general
-  statistics.
-
-- ZEO clients now support a client_label constructor argument and
-  client-label configuration-file option to specify a label for a
-  client in server logs. This makes it easier to identify specific
-  clients corresponding to server log entries, especially when there
-  are multiple clients originating from the same machine.
-
-- Improved ZEO server commit lock logging.  Now, locking activity is
-  logged at the debug level until the number of waiting lock requests
-  gets above 3.  Log at the critical level when the number of waiting
-  lock requests gets above 9.
-
-- The file-storage backup script, repozo, will now create a backup
-  index file if an output file name is given via the --output/-o
-  option.
-
-- Added a '--kill-old-on-full' argument to the repozo backup options:
-  if passed, remove any older full or incremental backup files from the
-  repository after doing a full backup.
-  (https://bugs.launchpad.net/zope2/+bug/143158)
-
-- The mkzeoinst script has been moved to a separate project:
-
-    http://pypi.python.org/pypi/zope.mkzeoinstance
-
-  and is no-longer included with ZODB.
-
-- Removed untested unsupported dbmstorage fossile.
-
-- ZEO servers no longer log their pids in every log message. It's just
-  not interesting. :)
-
-Bugs fixed
-----------
-
-- When a pool timeout was specified for a database and old connections
-  were removed due to timing out, an error occured due to a bug in the
-  connection cleanup logic.
-
-- When multi-database connections were no longer used and cleaned up,
-  their subconnections weren't cleaned up properly.
-
-- ZEO didn't work with IPv6 addrsses.
-  Added IPv6 support contributed by Martin v. Löwis.
-
-- A file storage bug could cause ZEO clients to have incorrect
-  information about current object revisions after reconnecting to a
-  database server.
-
-- Updated the 'repozo --kill-old-on-full' option to remove any '.index'
-  files corresponding to backups being removed.
-
-- ZEO extension methods failed when a client reconnected to a
-  storage. (https://bugs.launchpad.net/zodb/+bug/143344)
-
-- Clarified the return Value for lastTransaction in the case when
-  there aren't any transactions.  Now a string of 8 nulls (aka "z64")
-  is specified.
-
-- Setting _p_changed on a blob wo actually writing anything caused an
-  error. (https://bugs.launchpad.net/zodb/+bug/440234)
-
-- The verbose mode of the fstest was broken.
-  (https://bugs.launchpad.net/zodb/+bug/475996)
-
-- Object ids created in a savepoint that is rolled back wren't being
-  reused. (https://bugs.launchpad.net/zodb/+bug/588389)
-
-- Database connections didn't invalidate cache entries when conflict
-  errors were raised in response to checkCurrentSerialInTransaction
-  errors. Normally, this shouldn't be a problem, since there should be
-  pending invalidations for these oids which will cause the object to
-  be invalidated. There have been issues with ZEO persistent cache
-  management that have caused out of date data to remain in the cache.
-  (It's possible that the last of these were addressed in the
-  3.10.0b5.) Invalidating read data when there is a conflict error
-  provides some extra insurance.
-
-- The interface, ZODB.interfaces.IStorage was incorrect. The store
-  method should never return a sequence of oid and serial pairs.
-
-- When a demo storage push method was used to create a new demo
-  storage and the new storage was closed, the original was
-  (incorrectly) closed.
-
-- There were numerous bugs in the ZEO cache tracing and analysis code.
-  Cache simulation, while not perfect, seems to be much more accurate
-  now than it was before.
-
-  The ZEO cache trace statistics and simulation scripts have been
-  given more descriptive names and moved to the ZEO scripts package.
-
-- BTree sets and tree sets didn't correctly check values passed to
-  update or to constructors, causing Python to exit under certain
-  circumstances.
-
-- Fixed bug in copying a BTrees.Length instance.
-  (https://bugs.launchpad.net/zodb/+bug/516653)
-
-- Fixed a serious bug that caused cache failures when run
-  with Python optimization turned on.
-
-  https://bugs.launchpad.net/zodb/+bug/544305
-
-- When using using a ClientStorage in a Storage server, there was a
-  threading bug that caused clients to get disconnected.
-
-- On Mac OS X, clients that connected and disconnected quickly could
-  cause a ZEO server to stop accepting connections, due to a failure
-  to catch errors in the initial part of the connection process.
-
-  The failure to properly handle exceptions while accepting
-  connections is potentially problematic on other platforms.
-
-  Fixes: https://bugs.launchpad.net/zodb/+bug/135108
-
-- Object state management wasn't done correctly when classes
-  implemented custom _p_deavtivate methods.
-  (https://bugs.launchpad.net/zodb/+bug/185066)

Deleted: ZODB/trunk/COPYING
===================================================================
--- ZODB/trunk/COPYING	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/COPYING	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,5 +0,0 @@
-See:
-
- - the copyright notice in: COPYRIGHT.txt
-
- - The Zope Public License in LICENSE.txt

Deleted: ZODB/trunk/COPYRIGHT.txt
===================================================================
--- ZODB/trunk/COPYRIGHT.txt	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/COPYRIGHT.txt	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1 +0,0 @@
-Zope Foundation and Contributors
\ No newline at end of file

Deleted: ZODB/trunk/HISTORY.txt
===================================================================
--- ZODB/trunk/HISTORY.txt	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/HISTORY.txt	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,3997 +0,0 @@
-
-3.9.7 (2010-09-28)
-==================
-
-Bugs Fixed
-----------
-
-- Changes in way that garbage collection treats dictionaries in Python
-  2.7 broke the object/connection cache implementation.
-  (https://bugs.launchpad.net/zodb/+bug/641481)
-
-  Python 2.7 wasn't officially supported, but we were releasing
-  binaries for it, so ...
-
-- Logrotation/repoening via a SIGUSR2 signal wasn't implemented.
-  (https://bugs.launchpad.net/zodb/+bug/143600)
-
-- When using multi-databases, cache-management operations on a
-  connection, cacheMinimize and cacheGC, weren't applied to
-  subconnections.
-
-3.9.6 (2010-09-21)
-==================
-
-Bugs Fixed
-----------
-
-- Updating blobs in save points could cause spurious "invalidations
-  out of order" errors.  https://bugs.launchpad.net/zodb/+bug/509801
-
-  (Thanks to Christian Zagrodnick for chasing this down.)
-
-- If a ZEO client process was restarted while invalidating a ZEO cache
-  entry, the cache could be left in a stage when there is data marked
-  current that should be invalidated, leading to persistent conflict
-  errors.
-
-- Corrupted or invalid cache files prevented ZEO clients from
-  starting. Now, bad cache files are moved aside.
-
-- Invalidations of object records in ZEO caches, where the
-  invalidation transaction ids matched the cached transaction ids
-  should have been ignored.
-
-- Shutting down a process while committing a transaction or processing
-  invalidations from the server could cause ZEO persistent client
-  caches to have invalid data.  This, in turn caused stale data to
-  remain in the cache until it was updated.
-
-- Conflict errors didn't invalidate ZEO cache entries.
-
-- When objects were added in savepoints and either the savepoint was
-  rolled back (https://bugs.launchpad.net/zodb/+bug/143560) or the
-  transaction was aborted
-  (https://mail.zope.org/pipermail/zodb-dev/2010-June/013488.html)
-  The objects' _p_oid and _p_jar variables weren't cleared, leading to
-  surprizing errors.
-
-- Objects added in transactions that were later aborted could have
-  _p_changed still set (https://bugs.launchpad.net/zodb/+bug/615758).
-
-- ZEO extension methods failed when a client reconnected to a
-  storage. (https://bugs.launchpad.net/zodb/+bug/143344)
-
-- On Mac OS X, clients that connected and disconnected quickly could
-  cause a ZEO server to stop accepting connections, due to a failure
-  to catch errors in the initial part of the connection process.
-
-  The failure to properly handle exceptions while accepting
-  connections is potentially problematic on other platforms.
-
-  Fixes: https://bugs.launchpad.net/zodb/+bug/135108
-
-- Passing keys or values outside the range of 32-bit ints on 64-bit
-  platforms led to undetected overflow errors. Now these cases cause
-  Type errors to be raised.
-
-  https://bugs.launchpad.net/zodb/+bug/143237
-
-- BTree sets and tree sets didn't correctly check values passed to
-  update or to constructors, causing Python to exit under certain
-  circumstances.
-
-- The verbose mode of the fstest was broken.
-  (https://bugs.launchpad.net/zodb/+bug/475996)
-
-3.9.5 (2010-04-23)
-==================
-
-Bugs Fixed
-----------
-
-- Fixed bug in cPickleCache's byte size estimation logic.
-  (https://bugs.launchpad.net/zodb/+bug/533015)
-
-- Fixed a serious bug that caused cache failures when run
-  with Python optimization turned on.
-
-  https://bugs.launchpad.net/zodb/+bug/544305
-
-- Fixed a bug that caused savepoint rollback to not properly
-  set object state when objects implemented _p_invalidate methods
-  that reloaded ther state (unghostifiable objects).
-
-  https://bugs.launchpad.net/zodb/+bug/428039
-
-- cross-database wekrefs weren't handled correctly.
-
-  https://bugs.launchpad.net/zodb/+bug/435547
-
-- The mkzeoinst script was fixed to tell people to
-  install and use the mkzeoinstance script. :)
-
-3.9.4 (2009-12-14)
-==================
-
-Bugs Fixed
-----------
-
-- A ZEO threading bug could cause transactions to read inconsistent
-  data.  (This sometimes caused an AssertionError in
-  Connection._setstate_noncurrent.)
-
-- DemoStorage.loadBefore sometimes returned invalid data which
-  would trigger AssertionErrors in ZODB.Connection.
-
-- History support was broken when using stprages that work with ZODB
-  3.8 and 3.9.
-
-- zope.testing was an unnecessary non-testing dependency.
-
-- Internal ZEO errors were logged at the INFO level, rather
-  than at the error level.
-
-- The FileStorage backup and restore script, repozo, gave a
-  deprecation warning under Python 2.6.
-
-- C Header files weren't installed correctly.
-
-- The undo implementation was incorrect in ways that could cause
-  subtle missbehaviors.
-
-3.9.3 (2009-10-23)
-==================
-
-Bugs Fixed
-----------
-
-- 2 BTree bugs, introduced by a bug fix in 3.9.0c2, sometimes caused
-  deletion of keys to be improperly handled, resulting in data being
-  available via iteraation but not item access.
-
-3.9.2 (2009-10-13)
-==================
-
-Bugs Fixed
-----------
-
-- ZEO manages a separate thread for client network IO.  It created
-  this thread on import, which caused problems for applications that
-  implemented daemon behavior by forking.  Now, the client thread
-  isn't created until needed.
-
-- File-storage pack clean-up tasks that can take a long time
-  unnecessarily blocked other activity.
-
-- In certain rare situations, ZEO client connections would hang during
-  the initial connection setup.
-
-3.9.1 (2009-10-01)
-==================
-
-Bugs Fixed
-----------
-
-- Conflict errors committing blobs caused ZEO servers to stop committing
-  transactions.
-
-3.9.0 (2009-09-08)
-==================
-
-New Features (in more or less reverse chronological order)
-----------------------------------------------------------
-
-- The Database class now has an ``xrefs`` keyword argument and a
-  corresponding allow-implicit-cross-references configuration option.
-  which default to true.  When set to false, cross-database references
-  are disallowed.
-
-- Added support for RelStorage.
-
-- As a convenience, the connection root method for returning the root
-  object can now *also* be used as an object with attributes mapped to
-  the root-object keys.
-
-- Databases have a new method, ``transaction``, that can be used with the
-  Python (2.5 and later) ``with`` statement::
-
-     db = ZODB.DB(...)
-     with db.transaction() as conn:
-          # ... do stuff with conn
-
-  This uses a private transaction manager for the connection.
-  If control exits the block without an error, the transaction is
-  committed, otherwise, it is aborted.
-
-- Convenience functions ZODB.connection and ZEO.connection provide a
-  convenient way to open a connection to a database.  They open a
-  database and return a connection to it. When the connection is
-  closed, the database is closed as well.
-
-- The ZODB.config databaseFrom... methods now support
-  multi-databases. If multiple zodb sections are used to define
-  multiple databases, the databases are connected in a multi-database
-  arrangement and the first of the defined databases is returned.
-
-- The zeopack script has gotten a number of improvements:
-
-  - Simplified command-line interface. (The old interface is still
-    supported, except that support for ZEO version 1 servers has been
-    dropped.)
-
-  - Multiple storages can be packed in sequence.
-
-    - This simplifies pack scheduling on servers serving multiple
-      databases.
-
-    - All storages are packed to the same time.
-
-  - You can now specify a time of day to pack to.
-
-  - The script will now time out if it can't connect to s storage in
-    60 seconds.
-
-- The connection now estimates the object size based on its pickle size
-  and informs the cache about size changes.
-
-  The database got additional configurations options (`cache-size-bytes`
-  and `historical-cache-size-bytes`) to limit the
-  cache size based on the estimated total size of cached objects.
-  The default values are 0 which has the interpretation "do not limit
-  based on the total estimated size".
-  There are corresponding methods to read and set the new configuration
-  parameters.
-
-- Connections now have a public ``opened`` attribute that is true when
-  the connection is open, and false otherwise.  When true, it is the
-  seconds since the epoch (time.time()) when the connection was
-  opened. This is a renaming of the previous ``_opened`` private
-  variable.
-
-- FileStorage now supports blobs directly.
-
-- You can now control whether FileStorages keep .old files when packing.
-
-- POSKeyErrors are no longer logged by ZEO servers, because they are
-  really client errors.
-
-- A new storage interface, IExternalGC, to support external garbage
-  collection, http://wiki.zope.org/ZODB/ExternalGC, has been defined
-  and implemented for FileStorage and ClientStorage.
-
-- As a small convenience (mainly for tests), you can now specify
-  initial data as a string argument to the Blob constructor.
-
-- ZEO Servers now provide an option, invalidation-age, that allows
-  quick verification of ZEO clients have been disconnected for less
-  than a given time even if the number of transactions the client
-  hasn't seen exceeds the invalidation queue size. This is only
-  recommended if the storage being served supports efficient iteration
-  from a point near the end of the transaction history.
-
-- The FileStorage iterator now handles large files better.  When
-  iterating from a starting transaction near the end of the file, the
-  iterator will scan backward from the end of the file to find the
-  starting point.  This enhancement makes it practical to take
-  advantage of the new storage server invalidation-age option.
-
-- Previously, database connections were managed as a stack.  This
-  tended to cause the same connection(s) to be used over and over.
-  For example, the most used connection would typically be the only
-  connection used.  In some rare situations, extra connections could
-  be opened and end up on the top of the stack, causing extreme memory
-  wastage.  Now, when connections are placed on the stack, they sink
-  below existing connections that have more active objects.
-
-- There is a new pool-timeout database configuration option to specify that
-  connections unused after the given time interval should be garbage
-  collection.  This will provide a means of dealing with extra
-  connections that are created in rare circumstances and that would
-  consume an unreasonable amount of memory.
-
-- The Blob open method now supports a new mode, 'c', to open committed
-  data for reading as an ordinary file, rather than as a blob file.
-  The ordinary file may be used outside the current transaction and
-  even after the blob's database connection has been closed.
-
-- ClientStorage now provides blob cache management. When using
-  non-shared blob directories, you can set a target cache size and the
-  cache will periodically be reduced try to keep it below the target size.
-
-  The client blob directory layout has changed.  If you have existing
-  non-shared blob directories, you will have to remove them.
-
-- ZODB 3.9 ZEO clients can connect to ZODB 3.8 servers.  ZODB ZEO clients
-  from ZODB 3.2 on can connect to ZODB 3.9 servers.
-
-- When a ZEO cache is stale and would need verification, a
-  ZEO.interfaces.StaleCache event is published (to zope.event).
-  Applications may handle this event and take action such as exiting
-  the application without verifying the cache or starting cold.
-
-- There's a new convenience function, ZEO.DB, for creating databases
-  using ZEO Client Storages.  Just call ZEO.DB with the same arguments
-  you would otherwise pass to ZEO.ClientStorage.ClientStorage::
-
-    import ZEO
-    db = ZEO.DB(('some_host', 8200))
-
-- Object saves are a little faster
-
-- When configuring storages in a storage server, the storage name now
-  defaults to "1".  In the overwhelmingly common case that a single
-  storage, the name can now be omitted.
-
-- FileStorage now provides optional garbage collection.  A 'gc'
-  keyword option can be passed to the pack method.  A false value
-  prevents garbage collection.
-
-- The FileStorage constructor now provides a boolean pack_gc option,
-  which defaults to True, to control whether garbage collection is
-  performed when packing by default. This can be overridden with the
-  gc option to the pack method.
-
-  The ZConfig configuration for FileStorage now includes a pack-gc
-  option, corresponding to the pack_gc constructor argument.
-
-- The FileStorage constructor now has a packer keyword argument that
-  allows an alternative packer to be supplied.
-
-  The ZConfig configuration for FileStorage now includes a packer
-  option, corresponding to the packer constructor argument.
-
-- MappingStorage now supports multi-version concurrency control and
-  iteration and provides a better storage implementation example.
-
-- DemoStorage has a number of new features:
-
-  - The ability to use a separate storage, such as a file storage to
-    store changes
-
-  - Blob support
-
-  - Multi-version concurrency control and iteration
-
-  - Explicit support for demo-storage stacking via push and pop methods.
-
-- Wen calling ZODB.DB to create a database, you can now pass a file
-  name, rather than a storage to use a file storage.
-
-- Added support for copying and recovery of blob storages:
-
-  - Added a helper function, ZODB.blob.is_blob_record for testing whether
-    a data record is for a blob.  This can be used when iterating over a
-    storage to detect blob records so that blob data can be copied.
-
-    In the future, we may want to build this into a blob-aware
-    iteration interface, so that records get blob file attributes
-    automatically.
-
-  - Added the IBlobStorageRestoreable interfaces for blob storages
-    that support recovery via a restoreBlob method.
-
-  - Updated ZODB.blob.BlobStorage to implement
-    IBlobStorageRestoreable and to have a copyTransactionsFrom method
-    that also copies blob data.
-
-- New `ClientStorage` configuration option `drop_cache_rather_verify`.
-  If this option is true then the ZEO client cache is dropped instead of
-  the long (unoptimized) verification. For large caches, setting this
-  option can avoid effective down times in the order of hours when
-  the connection to the ZEO server was interrupted for a longer time.
-
-- Cleaned-up the storage iteration API and provided an iterator implementation
-  for ZEO.
-
-- Versions are no-longer supported.
-
-- Document conflict resolution (see ZODB/ConflictResolution.txt).
-
-- Support multi-database references in conflict resolution.
-
-- Make it possible to examine oid and (in some situations) database
-  name of persistent object references during conflict resolution.
-
-- Moved the 'transaction' module out of ZODB.
-  ZODB depends upon this module, but it must be installed separately.
-
-- ZODB installation now requires setuptools.
-
-- Added `offset` information to output of `fstail`
-  script. Added test harness for this script.
-
-- Added support for read-only, historical connections based
-  on datetimes or serials (TIDs).  See
-  src/ZODB/historical_connections.txt.
-
-- Removed the ThreadedAsync module.
-
-- Now depend on zc.lockfile
-
-Bugs Fixed
-----------
-
-- CVE-2009-2701: Fixed a vulnerability in ZEO storage servers when
-  blobs are available. Someone with write access to a ZEO server
-  configured to support blobs could read any file on the system
-  readable by the server process and remove any file removable by the
-  server process.
-
-- BTrees (and TreeSets) kept references to internal keys.
-  https://bugs.launchpad.net/zope3/+bug/294788
-
-- BTree Sets and TreeSets don't support the standard set add method.
-  (Now either add or the original insert method can be used to add an
-  object to a BTree-based set.)
-
-- The runzeo script didn't work without a configuration file.
-  (https://bugs.launchpad.net/zodb/+bug/410571)
-
-- Officially deprecated PersistentDict
-  (https://bugs.launchpad.net/zodb/+bug/400775)
-
-- Calling __setstate__ on a persistent object could under certain
-  uncommon cause the process to crash.
-  (https://bugs.launchpad.net/zodb/+bug/262158)
-
-- When committing transactions involving blobs to ClientStorages with
-  non-shared blob directories, a failure could occur in tpc_finish if
-  there was insufficient disk space to copy the blob file or if the
-  file wasn't available.  https://bugs.launchpad.net/zodb/+bug/224169
-
-- Savepoint blob data wasn't properly isolated. If multiple
-  simultaneous savepoints in separate transactions modified the same
-  blob, data from one savepoint would overwrite data for another.
-
-- Savepoint blob data wasn't cleaned up after a transaction abort.
-  https://bugs.launchpad.net/zodb/+bug/323067
-
-- Opening a blob with modes 'r+' or 'a' would fail when the blob had no
-  committed changes.
-
-- PersistentList's sort method did not allow passing of keyword parameters.
-  Changed its sort parameter list to match that of its (Python 2.4+)
-  UserList base class.
-
-- Certain ZEO server errors could cause a client to get into a state
-  where it couldn't commit transactions.
-  https://bugs.launchpad.net/zodb/+bug/374737
-
-- Fixed vulnerabilities in the ZEO network protocol that allow:
-
-  - CVE-2009-0668 Arbitrary Python code execution in ZODB ZEO storage servers
-  - CVE-2009-0669 Authentication bypass in ZODB ZEO storage servers
-
-  The vulnerabilities only apply if you are using ZEO to share a
-  database among multiple applications or application instances and if
-  untrusted clients are able to connect to your ZEO servers.
-
-- Fixed the setup test command.  It previously depended on private
-  functions in zope.testing.testrunner that don't exist any more.
-
-- ZEO client threads were unnamed, making it hard to debug thread
-  management.
-
-- ZEO protocol 2 support was broken.  This caused very old clients to
-  be unable to use new servers.
-
-- zeopack was less flexible than it was before.  -h should default to
-  local host.
-
-- The "lawn" layout was being selected by default if the root of
-  the blob directory happened to contain a hidden file or directory
-  such as ".svn".  Now hidden files and directories are ignored
-  when choosing the default layout.
-
-- BlobStorage was not compatible with MVCC storages because the
-  wrappers were being removed by each database connection.  Fixed.
-
-- Saving indexes for large file storages failed (with the error:
-  RuntimeError: maximum recursion depth exceeded).  This can cause a
-  FileStorage to fail to start because it gets an error trying to save
-  its index.
-
-- Sizes of new objects weren't added to the object cache size
-  estimation, causing the object-cache size limiting feature to let
-  the cache grow too large when many objects were added.
-
-- Deleted records weren't removed when packing file storages.
-
-- Fixed analyze.py and added test.
-
-- fixed Python 2.6 compatibility issue with ZEO/zeoserverlog.py
-
-- using hashlib.sha1 if available in order to avoid DeprecationWarning
-  under Python 2.6
-
-- made runzeo -h work
-
-- The monitor server didn't correctly report the actual number of
-  clients.
-
-- Packing could return spurious errors due to errors notifying
-  disconnected clients of new database size statistics.
-
-- Undo sometimes failed for FileStorages configured to support blobs.
-
-- Starting ClientStorages sometimes failed with non-new but empty
-  cache files.
-
-- The history method on ZEO clients failed.
-
-- Fix for bug #251037: Make packing of blob storages non-blocking.
-
-- Fix for bug #220856: Completed implementation of ZEO authentication.
-
-- Fix for bug #184057: Make initialisation of small ZEO client file cache
-  sizes not fail.
-
-- Fix for bug #184054: MappingStorage used to raise a KeyError during `load`
-  instead of a POSKeyError.
-
-- Fixed bug in Connection.TmpStore: load() would not defer to the backend
-  storage for loading blobs.
-
-- Fix for bug #181712: Make ClientStorage update `lastTransaction` directly
-  after connecting to a server, even when no cache verification is necessary.
-
-- Fixed bug in blob filesystem helper: the `isSecure` check was inverted.
-
-- Fixed bug in transaction buffer: a tuple was unpacked incorrectly in
-  `clear`.
-
-- Bugfix the situation in which comparing persistent objects (for
-  instance, as members in BTree set or keys of BTree) might cause data
-  inconsistency during conflict resolution.
-
-- Fixed bug 153316: persistent and BTrees were using `int`
-  for memory sizes which caused errors on x86_64 Intel Xeon machines
-  (using 64-bit Linux).
-
-- Fixed small bug that the Connection.isReadOnly method didn't
-  work after a savepoint.
-
-- Bug #98275: Made ZEO cache more tolerant when invalidating current
-  versions of objects.
-
-- Fixed a serious bug that could cause client I/O to stop
-  (hang). This was accompanied by a critical log message along the
-  lines of: "RuntimeError: dictionary changed size during iteration".
-
-- Fixed bug #127182: Blobs were subclassable which was not desired.
-
-- Fixed bug #126007: tpc_abort had untested code path that was
-  broken.
-
-- Fixed bug #129921: getSize() function in BlobStorage could not
-  deal with garbage files
-
-- Fixed bug in which MVCC would not work for blobs.
-
-- Fixed bug in ClientCache that occurred with objects larger than the total
-  cache size.
-
-- When an error occured attempting to lock a file and logging of said error was
-  enabled.
-
-- FileStorages previously saved indexes after a certain
-  number of writes.  This was done during the last phase of two-phase
-  commit, which made this critical phase more subject to errors than
-  it should have been.  Also, for large databases, saves were done so
-  infrequently as to be useless.  The feature was removed to reduce
-  the chance for errors during the last phase of two-phase commit.
-
-- File storages previously kept an internal object id to
-  transaction id mapping as an optimization. This mapping caused
-  excessive memory usage and failures during the last phase of
-  two-phase commit. This optimization has been removed.
-
-- Refactored handling of invalidations on ZEO clients to fix
-  a possible ordering problem for invalidation messages.
-
-- On many systems, it was impossible to create more than 32K
-  blobs. Added a new blob-directory layout to work around this
-  limitation.
-
-- Fixed bug that could lead to memory errors due to the use
-  of a Python dictionary for a mapping that can grow large.
-
-- Fixed bug #251037: Made packing of blob storages non-blocking.
-
-- Fixed a bug that could cause InvalidObjectReference errors
-  for objects that were explicitly added to a database if the object
-  was modified after a savepoint that added the object.
-
-- Fixed several bugs that caused ZEO cache corruption when connecting
-  to servers. These bugs affected both persistent and non-persistent caches.
-
-- Improved the the ZEO client shutdown support to try to
-  avoid spurious errors on exit, especially for scripts, such as zeopack.
-
-- Packing failed for databases containing cross-database references.
-
-- Cross-database references to databases with empty names
-  weren't constructed properly.
-
-- The zeo client cache used an excessive amount of memory, causing applications
-  with large caches to exhaust available memory.
-
-- Fixed a number of bugs in the handling of persistent ZEO caches:
-
-  - Cache records are written in several steps.  If a process exits
-    after writing begins and before it is finishes, the cache will be
-    corrupt on restart.  The way records are written was changed to
-    make cache record updates atomic.
-
-  - There was no lock file to prevent opening a cache multiple times
-    at once, which would lead to corruption.  Persistent caches now
-    use lock files, in the same way that file storages do.
-
-  - A bug in the cache-opening logic led to cache failure in the
-    unlikely event that a cache has no free blocks.
-
-- When using ZEO Client Storages, Errors occured when trying to store
-  objects too big to fit in the ZEO cache file.
-
-- Fixed bug in blob filesystem helper: the `isSecure` check was inverted.
-
-- Fixed bug in transaction buffer: a tuple was unpacked incorrectly in
-  `clear`.
-
-- Fixed bug in Connection.TmpStore: load() would not defer to the
-  back-end storage for loading blobs.
-
-- Fixed bug #190884: Wrong reference to `POSKeyError` caused NameError.
-
-- Completed implementation of ZEO authentication. This fixes issue 220856.
-
-
-What's new in ZODB 3.8.0
-========================
-
-General
--------
-
-- (unreleased) Fixed setup.py use of setuptools vs distutils, so .c and .h
-  files are included in the bdist_egg.
-
-- The ZODB Storage APIs have been documented and cleaned up.
-
-- ZODB versions are now officially deprecated and support for them
-  will be removed in ZODB 3.9.  (They have been widely recognized as
-  deprecated for quite a while.)
-
-- Changed the automatic garbage collection when opening a connection to only
-  apply the garbage collections on those connections in the pool that are
-  closed. (This fixed issue 113923.)
-
-ZEO
----
-
-- (3.8a1) ZEO's strategoes for avoiding client cache verification were
-  improved in the case that servers are restarted.  Before, if
-  transactions were committed after the restart, clients that were up
-  to date or nearly up to date at the time of the restart and then
-  connected had to verify their caches.  Now, it is far more likely
-  that a client that reconnects soon after a server restart won't have
-  to verify its cache.
-
-- (3.8a1) Fixed a serious bug that could cause clients that disconnect from and
-  reconnect to a server to get bad invalidation data if the server
-  serves multiple storages with active writes.
-
-- (3.8a1) It is now theoretically possible to use a ClientStorage in a storage
-  server.  This might make it possible to offload read load from a
-  storage server at the cost of increasing write latency.  This should
-  increase write throughput by offloading reads from the final storage
-  server.  This feature is somewhat experimental.  It has tests, but
-  hasn't been used in production.
-
-Transactions
-------------
-
-- (3.8a1) Add a doom() and isDoomed() interface to the transaction module.
-
-  First step towards the resolution of
-  http://www.zope.org/Collectors/Zope3-dev/655
-
-  A doomed transaction behaves exactly the same way as an active transaction
-  but raises an error on any attempt to commit it, thus forcing an abort.
-
-  Doom is useful in places where abort is unsafe and an exception cannot be
-  raised.  This occurs when the programmer wants the code following the doom to
-  run but not commit. It is unsafe to abort in these circumstances as a
-  following get() may implicitly open a new transaction.
-
-  Any attempt to commit a doomed transaction will raise a DoomedTransaction
-  exception.
-
-- (3.8a1) Clean up the ZODB imports in transaction.
-
-  Clean up weird import dance with ZODB. This is unnecessary since the
-  transaction module stopped being imported in ZODB/__init__.py in rev 39622.
-
-- (3.8a1) Support for subtransactions has been removed in favor of
-  save points.
-
-Blobs
------
-
-- (3.8b1) Updated the Blob implementation in a number of ways.  Some
-  of these are backward incompatible with 3.8a1:
-
-  o The Blob class now lives in ZODB.blob
-
-  o The blob openDetached method has been replaced by the committed method.
-
-- (3.8a1) Added new blob feature. See the ZODB/Blobs directory for
-  documentation.
-
-  ZODB now handles (reasonably) large binary objects efficiently. Useful to
-  use from a few kilobytes to at least multiple hundred megabytes.
-
-BTrees
-------
-
-- (3.8a1) Added support for 64-bit integer BTrees as separate types.  
-
-  (For now, we're retaining compile-time support for making the regular
-  integer BTrees 64-bit.)
-
-- (3.8a1) Normalize names in modules so that BTrees, Buckets, Sets, and
-  TreeSets can all be accessed with those names in the modules (e.g.,
-  BTrees.IOBTree.BTree).  This is in addition to the older names (e.g.,
-  BTrees.IOBTree.IOBTree).  This allows easier drop-in replacement, which
-  can especially be simplify code for packages that want to support both
-  32-bit and 64-bit BTrees.
-
-- (3.8a1) Describe the interfaces for each module and actually declare
-  the interfaces for each.
-
-- (3.8a1) Fix module references so klass.__module__ points to the Python
-  wrapper module, not the C extension.
-
-- (3.8a1) introduce module families, to group all 32-bit and all 64-bit
-  modules.
-
-
-What's new in ZODB3 3.7.0
-==========================
-Release date: 2007-04-20
-
-Packaging
----------
-
-- (3.7.0b3) ZODB is now packaged without it's dependencies
-
-  ZODB no longer includes copies of dependencies such as 
-  ZConfig, zope.interface and so on.  It now treats these as
-  dependencies.  If ZODB is installed with easy_install or
-  zc.buildout, the dependencies will be installed automatically.
-
-
-- (3.7.0b3) ZODB is now a buildout
-
-  ZODB checkouts are now built and tested using zc.buildout.
-
-- (3.7b4) Added logic to avoid spurious errors from the logging system
-  on exit.
-
-- (3.7b2) Removed the "sync" mode for ClientStorage.  
-
-  Previously, a ClientStorage could be in either "sync" mode or "async"
-  mode.  Now there is just "async" mode.  There is now a dedicicated
-  asyncore main loop dedicated to ZEO clients.
-
-  Applications no-longer need to run an asyncore main loop to cause
-  client storages to run in async mode.  Even if an application runs an
-  asyncore main loop, it is independent of the loop used by client
-  storages. 
-
-  This addresses a test failure on Mac OS X,
-  http://www.zope.org/Collectors/Zope3-dev/650, that I believe was due
-  to a bug in sync mode. Some asyncore-based code was being called from
-  multiple threads that didn't expect to be.
-
-  Converting to always-async mode revealed some bugs that weren't caught
-  before because the tests ran in sync mode.  These problems could
-  explain some problems we've seen at times with clients taking a long
-  time to reconnect after a disconnect.
-
-  Added a partial heart beat to try to detect lost connections that
-  aren't otherwise caught,
-  http://mail.zope.org/pipermail/zodb-dev/2005-June/008951.html, by
-  perioidically writing to all connections during periods of inactivity.
-
-Connection management
----------------------
-
-- (3.7a1) When more than ``pool_size`` connections have been closed,
-  ``DB`` forgets the excess (over ``pool_size``) connections closed first.
-  Python's cyclic garbage collection can take "a long time" to reclaim them
-  (and may in fact never reclaim them if application code keeps strong
-  references to them), but such forgotten connections can never be opened
-  again, so their caches are now cleared at the time ``DB`` forgets them.
-  Most applications won't notice a difference, but applications that open
-  many connections, and/or store many large objects in connection caches,
-  and/or store limited resources (such as RDB connections) in connection
-  caches may benefit.
-
-BTrees
-------
-
-- Support for 64-bit integer keys and values has been provided as a
-  compile-time option for the "I" BTrees (e.g. IIBTree).
-
-Documentation
--------------
-
-- (3.7a1) Thanks to Stephan Richter for converting many of the doctest
-  files to ReST format.  These are now chapters in the Zope 3 apidoc too.
-
-IPersistent
------------
-
-- (3.7a1) The documentation for ``_p_oid`` now specifies the concrete
-  type of oids (in short, an oid is either None or a non-empty string).
-
-Testing
--------
-
-- (3.7b2) Fixed test-runner output truncation.
-
-  A bug was fixed in the test runner that caused result summaries to be
-  omitted when running on Windows.
-
-Tools
------
-
-- (3.7a1) The changeover from zLOG to the logging module means that some
-  tools need to perform minimal logging configuration themselves. Changed
-  the zeoup script to do so and thus enable it to emit error messages.
-
-BTrees
-------
-
-- (3.7a1) Suppressed warnings about signedness of characters when
-  compiling under GCC 4.0.x.  See http://www.zope.org/Collectors/Zope/2027.
-
-Connection
-----------
-
-- (3.7a1) An optimization for loading non-current data (MVCC) was
-  inadvertently disabled in ``_setstate()``; this has been repaired.
-
-persistent
-----------
-
-- (3.7a1) Suppressed warnings about signedness of characters when
-  compiling under GCC 4.0.x.  See http://www.zope.org/Collectors/Zope/2027.
-
-- (3.7a1) PersistentMapping was inadvertently pickling volatile attributes
-  (http://www.zope.org/Collectors/Zope/2052).
-
-After Commit hooks
-------------------
-
-- (3.7a1) Transaction objects have a new method,
-  ``addAfterCommitHook(hook, *args, **kws)``.  Hook functions
-  registered with a transaction are called after the transaction
-  commits or aborts. For example, one might want to launch non
-  transactional or asynchrnonous code after a successful, or aborted,
-  commit. See ``test_afterCommitHook()`` in
-  ``transaction/tests/test_transaction.py`` for a tutorial doctest,
-  and the ``ITransaction`` interface for details.
-
-
-What's new in ZODB3 3.6.2?
-==========================
-Release date: 15-July-2006
-
-
-DemoStorage
------------
-
-- (3.6.2) DemoStorage was unable to wrap base storages who did not have
-          an '_oid' attribute:  most notably, ZEO.ClientStorage
-          (http://www.zope.org/Collectors/Zope/2016).
-
-Following is combined news from internal releases (to support ongoing
-Zope2 / Zope3 development).  These are the dates of the internal releases:
-
-- 3.6.1 27-Mar-2006
-- 3.6.0 05-Jan-2006
-- 3.6b6 01-Jan-2006
-- 3.6b5 18-Dec-2005
-- 3.6b4 04-Dec-2005
-- 3.6b3 06-Nov-2005
-- 3.6b2 25-Oct-2005
-- 3.6b1 24-Oct-2005
-- 3.6a4 07-Oct-2005
-- 3.6a3 07-Sep-2005
-- 3.6a2 06-Sep-2005
-- 3.6a1 04-Sep-2005
-
-Removal of Features Deprecated in ZODB 3.4
-------------------------------------------
-
-(3.6b2) ZODB 3.6 no longer contains features officially deprecated in the
-ZODB 3.4 release.  These include:
-
-- ``get_transaction()``.  Use ``transaction.get()`` instead.
-  ``transaction.commit()`` is a shortcut spelling of
-  ``transaction.get().commit()``, and ``transaction.abort()``
-  of ``transaction.get().abort()``.  Note that importing ZODB no longer
-  installs ``get_transaction`` as a name in Python's ``__builtin__``
-  module either.
-
-- The ``begin()`` method of ``Transaction`` objects.  Use the ``begin()``
-  method of a transaction manager instead.  ``transaction.begin()`` is
-  a shortcut spelling to call the default transaction manager's ``begin()``
-  method.
-
-- The ``dt`` argument to ``Connection.cacheMinimize()``.
-
-- The ``Connection.cacheFullSweep()`` method.  Use ``cacheMinimize()``
-  instead.
-
-- The ``Connection.getTransaction()`` method.  Pass a transaction manager
-  to ``DB.open()`` instead.
-
-- The ``Connection.getLocalTransaction()`` method.  Pass a transaction
-  manager to ``DB.open()`` instead.
-
-- The ``cache_deactivate_after`` and ``version_cache_deactivate_after``
-  arguments to the ``DB`` constructor.
-
-- The ``temporary``, ``force``, and ``waitflag`` arguments
-  to ``DB.open()``.  ``DB.open()`` no longer blocks (there's no longer
-  a fixed limit on the number of open connections).
-
-- The ``transaction`` and ``txn_mgr``arguments to ``DB.open()``.  Use
-  the ``transaction_manager`` argument instead.
-
-- The ``getCacheDeactivateAfter``, ``setCacheDeactivateAfter``,
-  ``getVersionCacheDeactivateAfter`` and ``setVersionCacheDeactivateAfter``
-  methods of ``DB``.
-
-Persistent
-----------
-
-- (3.6.1) Suppressed warnings about signedness of characters when
-  compiling under GCC 4.0.x.  See http://www.zope.org/Collectors/Zope/2027.
-
-- (3.6a4) ZODB 3.6 introduces a change to the basic behavior of Persistent
-  objects in a particular end case.  Before ZODB 3.6, setting
-  ``obj._p_changed`` to a true value when ``obj`` was a ghost was ignored:
-  ``obj`` remained a ghost, and getting ``obj._p_changed`` continued to
-  return ``None``.  Starting with ZODB 3.6, ``obj`` is activated instead
-  (unghostified), and its state is changed from the ghost state to the
-  changed state.  The new behavior is less surprising and more robust.
-
-- (3.6b5) The documentation for ``_p_oid`` now specifies the concrete
-  type of oids (in short, an oid is either None or a non-empty string).
-
-Commit hooks
-------------
-
-- (3.6a1) The ``beforeCommitHook()`` method has been replaced by the new
-  ``addBeforeCommitHook()`` method, with a more-robust signature.
-  ``beforeCommitHook()`` is now deprecated, and will be removed in ZODB 3.8.
-  Thanks to Julien Anguenot for contributing code and tests.
-
-Connection management
----------------------
-
-- (3.6b6) When more than ``pool_size`` connections have been closed,
-  ``DB`` forgets the excess (over ``pool_size``) connections closed first.
-  Python's cyclic garbage collection can take "a long time" to reclaim them
-  (and may in fact never reclaim them if application code keeps strong
-  references to them), but such forgotten connections can never be opened
-  again, so their caches are now cleared at the time ``DB`` forgets them.
-  Most applications won't notice a difference, but applications that open
-  many connections, and/or store many large objects in connection caches,
-  and/or store limited resources (such as RDB connections) in connection
-  caches may benefit.
-
-ZEO
----
-
-- (3.6a4) Collector 1900.  In some cases of pickle exceptions raised by
-  low-level ZEO communication code, callers of ``marshal.encode()`` could
-  attempt to catch an exception that didn't actually exist, leading to an
-  erroneous ``AttributeError`` exception.  Thanks to Tres Seaver for the
-  diagnosis.
-
-BaseStorage
------------
-
-- (3.6a4) Nothing done by ``tpc_abort()`` should raise an exception.
-  However, if something does (an error case), ``BaseStorage.tpc_abort()``
-  left the commit lock in the acquired state, causing any later attempt
-  to commit changes hang.
-
-Multidatabase
--------------
-
-- (3.6b1) The ``database_name`` for a database in a multidatabase
-  collection can now be specified in a config file's ``<zodb>`` section,
-  as the value of the optional new ``database_name`` key.  The
-  ``.databases`` attribute cannot be specified in a config file, but
-  can be passed as the optional new ``databases`` argument to the
-  ``open()`` method of a ZConfig factory for type ``ZODBDatabase``.
-  For backward compatibility, Zope 2.9 continues to allow using the
-  name in its ``<zodb_db name>`` config section as the database name
-  (note that ``<zodb_db>`` is defined by Zope, not by ZODB -- it's a
-  Zope-specific extension of ZODB's ``<zodb>`` section).
-
-PersistentMapping
------------------
-
-- (3.6.1) PersistentMapping was inadvertently pickling volatile attributes
-  (http://www.zope.org/Collectors/Zope/2052).
-
-- (3.6b4) ``PersistentMapping`` makes changes by a ``pop()`` method call
-  persistent now (http://www.zope.org/Collectors/Zope/2036).
-
-- (3.6a1) The ``PersistentMapping`` class has an ``__iter__()`` method
-  now, so that objects of this type work well with Python's iteration
-  protocol.  For example, if ``x`` is a ``PersistentMapping`` (or
-  Python dictionary, or BTree, or ``PersistentDict``, ...), then
-  ``for key in x:`` iterates over the keys of ``x``, ``list(x)`` creates
-  a list containing ``x``'s keys, ``iter(x)`` creates an iterator for
-  ``x``'s keys, and so on.
-
-Tools
------
-
-- (3.6b5) The changeover from zLOG to the logging module means that some
-  tools need to perform minimal logging configuration themselves. Changed
-  the zeoup script to do so and thus enable it to emit error messages.
-
-BTrees
-------
-
-- (3.6.1) Suppressed warnings about signedness of characters when
-  compiling under GCC 4.0.x.  See http://www.zope.org/Collectors/Zope/2027.
-
-- (3.6a1) BTrees and Buckets now implement the ``setdefault()`` and ``pop()``
-  methods. These are exactly like Python's dictionary methods of the same
-  names, except that ``setdefault()`` requires both arguments (and Python is
-  likely to change to require both arguments too -- defaulting the
-  ``default`` argument to ``None`` has no viable use cases).  Thanks to
-  Ruslan Spivak for contributing code, tests, and documentation.
-
-- (3.6a1) Collector 1873.  It wasn't possible to construct a BTree or Bucket
-  from, or apply their update() methods to, a PersistentMapping or
-  PersistentDict.  This works now.
-
-ZopeUndo
---------
-
-- (3.6a4) Collector 1810. A previous bugfix (#1726) broke listing undoable
-  transactions for users defined in a non-root acl_users folder. Zope logs
-  a acl_users path together with a username (separated by a space) and this
-  previous fix failed to take this into account.
-
-Connection
-----------
-
-- (3.6b5) An optimization for loading non-current data (MVCC) was
-  inadvertently disabled in ``_setstate()``; this has been repaired.
-
-Documentation
--------------
-
-- (3.6b3) Thanks to Stephan Richter for converting many of the doctest
-  files to ReST format.  These are now chapters in the Zope 3 apidoc too.
-
-- (3.6b4) Several misspellings of "occurred" were repaired.
-
-Development
------------
-
-- (3.6a1) The source code for the old ExtensionClass-based Persistence
-  package moved, from ZODB to the Zope 2.9 development tree.  ZODB 3.5
-  makes no use of Persistence, and, indeed, the Persistence package could
-  not be compiled from a ZODB release, since some of the C header files
-  needed appear only in Zope.
-
-- (3.6a3) Re-added the ``zeoctl`` module, for the same reasons
-  ``mkzeoinst`` was re-added (see below).
-
-- (3.6a2) The ``mkzeoinst`` module was re-added to ZEO, because Zope3
-  has a script that expects to import it from there.  ZODB's ``mkzeoinst``
-  script was rewritten to invoke the ``mkzeoinst`` module.
-
-``transact``
-------------
-
-- (3.6b4) Collector 1959:  The undocumented ``transact`` module no
-  longer worked.  It remains undocumented and untested, but thanks to
-  Janko Hauser it's possible that it works again ;-).
-
-What's new in ZODB3 3.5.1?
-==========================
-Release date: 26-Sep-2005
-
-Following is combined news from internal releases (to support ongoing
-Zope3 development).  These are the dates of the internal releases:
-
-- 3.5.1b2 07-Sep-2005
-- 3.5.1b1 06-Sep-2005
-
-Build
------
-
-- (3.5.1b2) Re-added the ``zeoctl`` module, for the same reasons
-  ``mkzeoinst`` was re-added (see below).
-
-- (3.5.1b1) The ``mkzeoinst`` module was re-added to ZEO, because Zope3
-  has a script that expects to import it from there.  ZODB's ``mkzeoinst``
-  script was rewritten to invoke the ``mkzeoinst`` module.
-
-ZopeUndo
---------
-
-- (3.5.1) Collector 1810. A previous bugfix (#1726) broke listing undoable
-  transactions for users defined in a non-root acl_users folder. Zope logs
-  a acl_users path together with a username (separated by a space) and this
-  previous fix failed to take this into account.
-
-
-What's new in ZODB3 3.5.0?
-==========================
-Release date: 31-Aug-2005
-
-Following is combined news from internal releases (to support ongoing
-Zope3 development).  These are the dates of the internal releases:
-
-- 3.5a7 11-Aug-2005
-- 3.5a6 04-Aug-2005
-- 3.5a5 19-Jul-2005
-- 3.5a4 14-Jul-2005
-- 3.5a3 17-Jun-2005
-- 3.5a2 16-Jun-2005
-- 3.5a1 10-Jun-2005
-
-Savepoints
-----------
-
-- (3.5.0) As for deprecated subtransaction commits, the intent was
-  that making a savepoint would invoke incremental garbage collection on
-  Connection memory caches, to try to reduce the number of objects in
-  cache to the configured cache size.  Due to an oversight, this didn't
-  happen, and stopped happening for subtransaction commits too.  Making a
-  savepoint (or doing a subtransaction commit) does invoke cache gc now.
-
-- (3.5a3) When a savepoint is made, the states of objects modified so far
-  are saved to a temporary storage (an instance of class ``TmpStore``,
-  although that's an internal implementation detail).  That storage needs
-  to implement the full storage API too, but was missing the ``loadBefore()``
-  method needed for MVCC to retrieve non-current revisions of objects.  This
-  could cause spurious errors if a transaction with a pending savepoint
-  needed to fetch an older revision of some object.
-
-- (3.5a4) The ``ISavepoint`` interface docs said you could roll back to a
-  given savepoint any number of times (until the transaction ends, or until
-  you roll back to an earlier savepoint's state), but the implementation
-  marked a savepoint as invalid after its first use.  The implementation has
-  been repaired, to match the docs.
-
-ZEO client cache
-----------------
-
-- (3.5a6) Two memory leaks in the ZEO client cache were repaired, a
-  major one involving ``ZEO.cache.Entry`` objects, and a minor one involving
-  empty lists.
-
-Subtransactions are deprecated
-------------------------------
-
-- (3.5a4) Subtransactions are deprecated, and will be removed in ZODB 3.7.
-  Use savepoints instead.  Savepoints are more powerful, and code using
-  subtransactions does not mix well with code using savepoints (a
-  subtransaction commit forces all current savepoints to become unusable, so
-  code using subtransactions can hurt newer code trying to use savepoints).
-  In general, a subtransaction commit done just to free memory can be changed
-  from::
-
-      transaction.commit(1)
-
-  to::
-
-      transaction.savepoint(True)
-
-  That is, make a savepoint, and forget it.  As shown, it's best to pass
-  ``True`` for the optional ``optimistic`` argument in this case:  because
-  there's no possibility of asking for a rollback later, there's no need
-  to insist that all data managers support rollback.
-
-  In rarer cases, a subtransaction commit is followed later by a
-  subtransaction abort.  In that case, change the initial::
-
-      transaction.commit(1)
-
-  to::
-
-      sp = transaction.savepoint()
-
-  and in place of the subtransaction abort::
-
-      transaction.abort(1)
-
-  roll back the savepoint instead::
-
-      sp.rollback()
-
-- (3.5a4) Internal uses of subtransactions (transaction ``commit()`` or
-  ``abort()`` passing a true argument) were rewritten to use savepoints
-  instead.
-
-Multi-database
---------------
-
-- (3.5a1) Preliminary support for persistent cross-database references has
-  been added.  See ``ZODB/cross-database-references.txt`` for an
-  introduction.
-
-Tools
------
-
-- (3.5a6, 3.5a7) Collector #1847.  The ZEO client cache tracing and simulation
-  tools weren't updated to work with ZODB 3.3, and the introduction of
-  MVCC required major reworking of the tracing and simulation code.  These
-  tools are in a working state again, although so far lightly tested on
-  just a few applications.  In ``doc/ZEO/``, see the heavily revised
-  ``trace.txt`` and ``cache.txt``.
-
-- (3.5a5) Collector #1846:  If an uncommitted transaction was found,
-  fsrecover.py fell into an infinite loop.
-
-Windows
--------
-
-- (3.5a6) As developed in a long thread starting at
-  http://mail.zope.org/pipermail/zope/2005-July/160433.html
-  there appears to be a race bug in the Microsoft Windows socket
-  implementation, rarely visible in ZEO when multiple processes try to
-  create an "asyncore trigger" simultaneously.  Windows-specific code in
-  ``ZEO/zrpc/trigger.py`` changed to work around this bug when it occurs.
-
-ThreadedAsync.LoopCallback
---------------------------
-
-- (3.5a5) This once again physically replaces Python's ``asyncore.loop``
-  function with its own loop function, because it turns out Zope relied on
-  the seemingly unused ``LoopCallback.exit_status`` global, which was
-  removed in the change described below.  Python's ``asyncore.loop`` is again
-  not invoked, so any breakpoints or debugging prints added to that are again
-  "lost".
-
-- (3.5a4) This replaces Python's ``asyncore.loop`` function with its own, in
-  order to get notified when ``loop()`` is first called.  The signature of
-  ``asyncore.loop`` changed in Python 2.4, but ``LoopCallback.loop``'s
-  signature didn't change to match.  The code here was repaired to be
-  compatible with both old and new signatures, and also repaired to invoke
-  Python's ``asyncore.loop()`` instead of replacing it entirely (so, for
-  example, debugging prints added to Python's ``asyncore.loop`` won't be
-  lost anymore).
-
-
-FileStorage
------------
-
-- (3.5a4) Collector #1830.  In some error cases when reading a FileStorage
-  index, the code referenced an undefined global.
-
-- (3.5a4) Collector #1822.  The ``undoLog()`` and ``undoInfo()`` methods
-  were changed in 3.4a9 to return the documented results.  Alas, some pieces
-  of (non-ZODB) code relied on the actual behavior.  When the ``first`` and
-  ``last`` arguments are both >= 0, these methods now treat them as if they
-  were Python slice indices, including the `first` index but excluding the
-  ``last`` index.  This matches former behavior, although it contradicts older
-  ZODB UML documentation.  The documentation in
-  ``ZODB.interfaces.IStorageUndoable`` was changed to match the new intent.
-
-- (3.5a2) The ``_readnext()`` method now returns the transaction size as
-  the value of the "size" key.  Thanks to Dieter Maurer for the patch, from
-  http://mail.zope.org/pipermail/zodb-dev/2003-October/006157.html. "This is
-  very valuable when you want to spot strange transaction sizes via Zope's
-  'Undo' tab".
-
-BTrees
-------
-
-- (3.5.a5) Collector 1843.  When a non-integer was passed to a method like
-  ``keys()`` of a Bucket or Set with integer keys, an internal error code
-  was overlooked, leading to everything from "delayed errors" to segfaults.
-  Such cases raise TypeError now, as intended.
-
-- (3.5a4) Collector 1831.  The BTree ``minKey()`` and ``maxKey()`` methods
-  gave a misleading message if no key satisfying the constraints existed in a
-  non-empty tree.
-
-- (3.5a4) Collector 1829.  Clarified that the ``minKey()`` and ``maxKey()``
-  methods raise an exception if no key exists satsifying the constraints.
-
-- (3.5a4) The ancient ``convert.py`` script was removed.  It was intended to
-  convert "old" BTrees to "new" BTrees, but the "old" BTree implementation
-  was removed from ZODB years ago.
-
-
-What's new in ZODB3 3.4.1?
-==========================
-Release date: 09-Aug-2005
-
-Following are dates of internal releases (to support ongoing Zope 2
-development) since ZODB 3.4's last public release:
-
-- 3.4.1b5 08-Aug-2005
-- 3.4.1b4 07-Aug-2005
-- 3.4.1b3 04-Aug-2005
-- 3.4.1b2 02-Aug-2005
-- 3.4.1b1 26-Jul-2005
-- 3.4.1a6 19-Jul-2005
-- 3.4.1a5 12-Jul-2005
-- 3.4.1a4 08-Jul-2005
-- 3.4.1a3 02-Jul-2005
-- 3.4.1a2 29-Jun-2005
-- 3.4.1a1 27-Jun-2005
-
-Savepoints
-----------
-
-- (3.4.1a1) When a savepoint is made, the states of objects modified so far
-  are saved to a temporary storage (an instance of class ``TmpStore``,
-  although that's an internal implementation detail).  That storage needs
-  to implement the full storage API too, but was missing the ``loadBefore()``
-  method needed for MVCC to retrieve non-current revisions of objects.  This
-  could cause spurious errors if a transaction with a pending savepoint
-  needed to fetch an older revision of some object.
-
-- (3.4.1a5) The ``ISavepoint`` interface docs said you could roll back to a
-  given savepoint any number of times (until the transaction ends, or until
-  you roll back to an earlier savepoint's state), but the implementation
-  marked a savepoint as invalid after its first use.  The implementation has
-  been repaired, to match the docs.
-
-- (3.4.1b4) Collector 1860:  use an optimistic savepoint in ExportImport
-  (there's no possiblity of rollback here, so no need to insist that the
-  data manager support rollbacks).
-
-ZEO client cache
-----------------
-
-- (3.4.1b3) Two memory leaks in the ZEO client cache were repaired, a
-  major one involving ``ZEO.cache.Entry`` objects, and a minor one involving
-  empty lists.
-
-Subtransactions
----------------
-
-- (3.4.1a5) Internal uses of subtransactions (transaction ``commit()`` or
-  ``abort()`` passing a true argument) were rewritten to use savepoints
-  instead.  Application code is strongly encouraged to do this too:
-  subtransactions are weaker, will be deprecated soon, and do not mix well
-  with savepoints (when you do a subtransaction commit, all current
-  savepoints are made unusable).  In general, a subtransaction commit
-  done just to free memory can be changed from::
-
-      transaction.commit(1)
-
-  to::
-
-      transaction.savepoint(True)
-
-  That is, make a savepoint, and forget it.  As shown, it's best to pass
-  ``True`` for the optional ``optimistic`` argument in this case:  because
-  there's no possibility of asking for a rollback later, there's no need
-  to insist that all data managers support rollback.
-
-  In rarer cases, a subtransaction commit is followed later by a
-  subtransaction abort.  In that case, change the initial::
-
-      transaction.commit(1)
-
-  to::
-
-      sp = transaction.savepoint()
-
-  and in place of the subtransaction abort::
-
-      transaction.abort(1)
-
-  roll back the savepoint instead::
-
-      sp.rollback()
-
-FileStorage
------------
-
-- (3.4.1a3) Collector #1830.  In some error cases when reading a FileStorage
-  index, the code referenced an undefined global.
-
-- (3.4.1a2) Collector #1822.  The ``undoLog()`` and ``undoInfo()`` methods
-  were changed in 3.4a9 to return the documented results.  Alas, some pieces
-  of (non-ZODB) code relied on the actual behavior.  When the `first` and
-  `last` arguments are both >= 0, these methods now treat them as if they
-  were Python slice indices, including the `first` index but excluding the
-  `last` index.  This matches former behavior, although it contradicts older
-  ZODB UML documentation.  The documentation in
-  ``ZODB.interfaces.IStorageUndoable`` was changed to match the new intent.
-
-- (3.4.1a1) The ``UndoSearch._readnext()`` method now returns the transaction
-  size as the value of the "size" key.  Thanks to Dieter Maurer for the
-  patch, from
-  http://mail.zope.org/pipermail/zodb-dev/2003-October/006157.html. "This is
-  very valuable when you want to spot strange transaction sizes via Zope's
-  'Undo' tab".
-
-ThreadedAsync.LoopCallback
---------------------------
-
-- (3.4.1a6) This once again physically replaces Python's ``asyncore.loop``
-  function with its own loop function, because it turns out Zope relied on
-  the seemingly unused ``LoopCallback.exit_status`` global, which was
-  removed in the change described below.  Python's ``asyncore.loop`` is again
-  not invoked, so any breakpoints or debugging prints added to that are again
-  "lost".
-
-- (3.4.1a1) This replaces Python's ``asyncore.loop`` function with its own,
-  in order to get notified when ``loop()`` is first called.  The signature of
-  ``asyncore.loop`` changed in Python 2.4, but ``LoopCallback.loop``'s
-  signature didn't change to match.  The code here was repaired to be
-  compatible with both old and new signatures, and also repaired to invoke
-  Python's ``asyncore.loop()`` instead of replacing it entirely (so, for
-  example, debugging prints added to Python's ``asyncore.loop`` won't be lost
-  anymore).
-
-Windows
--------
-
-- (3.4.1b2) As developed in a long thread starting at
-  http://mail.zope.org/pipermail/zope/2005-July/160433.html
-  there appears to be a race bug in the Microsoft Windows socket
-  implementation, rarely visible in ZEO when multiple processes try to
-  create an "asyncore trigger" simultaneously.  Windows-specific code in
-  ``ZEO/zrpc/trigger.py`` changed to work around this bug when it occurs.
-
-
-Tools
------
-
-- (3.4.1b1 thru 3.4.1b5) Collector #1847.  The ZEO client cache tracing and
-  simulation tools weren't updated to work with ZODB 3.3, and the
-  introduction of MVCC required major reworking of the tracing and simulation
-  code.  These tools are in a working state again, although so far lightly
-  tested on just a few applications.  In ``doc/ZEO/``, see the heavily revised
-  ``trace.txt`` and ``cache.txt``.
-
-- (3.4.1a6) Collector #1846:  If an uncommitted transaction was found,
-  fsrecover.py fell into an infinite loop.
-
-
-DemoStorage
------------
-
-- (3.4.1a1) The implementation of ``undoLog()`` was wrong in several ways;
-  repaired.
-
-BTrees
-------
-
-- (3.4.1a6) Collector 1843.  When a non-integer was passed to a method like
-  ``keys()`` of a Bucket or Set with integer keys, an internal error code
-  was overlooked, leading to everything from "delayed errors" to segfaults.
-  Such cases raise TypeError now, as intended.
-
-- (3.4.1a4) Collector 1831.  The BTree ``minKey()`` and ``maxKey()`` methods
-  gave a misleading message if no key satisfying the constraints existed in a
-  non-empty tree.
-
-- (3.4.1a3) Collector 1829.  Clarified that the ``minKey()`` and ``maxKey()``
-  methods raise an exception if no key exists satsifying the constraints.
-
-
-What's new in ZODB3 3.4?
-========================
-Release date: 09-Jun-2005
-
-Following is combined news from the "internal releases" (to support
-ongoing Zope 2.8 and Zope3 development) since the last public ZODB 3.4
-release.  These are the dates of the internal releases:
-
-- 3.4c2 06-Jun-2005
-- 3.4c1 03-Jun-2005
-- 3.4b3 27-May-2005
-- 3.4b2 26-May-2005
-
-Connection, DB
---------------
-
-- (3.4b3) ``.transaction_manager`` is now a public attribute of
-  IDataManager, and is the instance of ITransactionManager used by the
-  data manager as its transaction manager.  There was previously no way
-  to ask a data manager which transaction manager it was using.  It's
-  intended that ``transaction_manager`` be treated as read-only.
-
-- (3.4b3) For sanity, the ``txn_mgr`` argument to ``DB.open()``,
-  ``Connection.__init__()``, and ``Connection._setDB()`` has been renamed
-  to ``transaction_manager``.  ``txn_mgr`` is still accepted, but is
-  deprecated and will be removed in ZODB 3.6.  Any code that was using
-  the private ``._txn_mgr`` attribute of ``Connection`` will break
-  immediately.
-
-Development
------------
-
-- (3.4b2) ZODB's ``test.py`` is now a small driver for the shared
-  ``zope.testing.testrunner``.  See the latter's documentation
-  for command-line arguments.
-
-Error reporting
----------------
-
-- (3.4c1) In the unlikely event that ``referencesf()`` reports an unpickling
-  error (for example, a corrupt database can cause this), the message it
-  produces no longer contains unprintable characters.
-
-Tests
------
-
-- (3.4c2) ``checkCrossDBInvalidations`` suffered spurious failures too often
-  on slow and/or busy machines.  The test is willing to wait longer for
-  success now.
-
-
-What's new in ZODB3 3.4b1?
-==========================
-Release date: 19-May-2005
-
-What follows is combined news from the "internal releases" (to support
-ongoing Zope 2.8 and Zope3 development) since the last public ZODB 3.4
-release.  These are the dates of the internal releases:
-
-- 3.4b1 19-May-2005
-- 3.4a9 12-May-2005
-- 3.4a8 09-May-2005
-- 3.4a7 06-May-2005
-- 3.4a6 05-May-2005
-- 3.4a5 25-Apr-2005
-- 3.4a4 23-Apr-2005
-- 3.4a3 13-Apr-2005
-- 3.4a2 03-Apr-2005
-
-
-transaction
------------
-
-- (3.4a7) If the first activity seen by a new ``ThreadTransactionManager`` was
-  an explicit ``begin()`` call, then synchronizers registered after that (but
-  still during the first transaction) were not communicated to the
-  transaction object.  As a result, the ``afterCompletion()`` methods of
-  registered synchronizers weren't called when the first transaction ended.
-
-- (3.4a6) Doing a subtransaction commit erroneously processed invalidations,
-  which could lead to an inconsistent view of the database.  For example, let
-  T be the transaction of which the subtransaction commit was a part.  If T
-  read a persistent object O's state before the subtransaction commit, did not
-  commit new state of its own for O during its subtransaction commit, and O
-  was modified before the subtransaction commit by a different transaction,
-  then the subtransaction commit processed an invalidation for O, and the
-  state T read for O originally was discarded in T.  If T went on to access O
-  again, it saw the newly committed (by a different transaction) state for O::
-
-      o_attr = O.some_attribute
-      get_transaction().commit(True)
-      assert o_attr == O.some_attribute
-
-  could fail, and despite that T never modifed O.
-
-- (3.4a4) Transactions now support savepoints.  Savepoints allow changes to be
-  periodically checkpointed within a transaction.  You can then rollback to a
-  previously created savepoint.  See ``transaction/savepoint.txt``.
-
-- (3.4a6) A ``getBeforeCommitHooks()`` method was added.  It returns an
-  iterable producing the registered beforeCommit hooks.
-
-- (3.4a6) The ``ISynchronizer`` interface has a new ``newTransaction()``
-  method. This is invoked whenever a transaction manager's ``begin()`` method
-  is called.  (Note that a transaction object's (as opposed to a transaction
-  manager's) ``begin()`` method is deprecated, and ``newTransaction()`` is
-  not called when using the deprecated method.)
-
-- (3.4a6) Relatedly, ``Connection`` implements ``ISynchronizer``, and
-  ``Connection``'s ``afterCompletion()`` and ``newTransaction()`` methods now
-  call ``sync()`` on the underlying storage (if the underlying storage has
-  such a method), in addition to processing invalidations.  The practical
-  implication is that storage synchronization will be done automatically now,
-  whenever a transaction is explicitly started, and after top-level
-  transaction commit or abort.  As a result, ``Connection.sync()`` should
-  virtually never be needed anymore, and will eventually be deprecated.
-
-- (3.4a3) Transaction objects have a new method, ``beforeCommitHook(hook,
-  *args, **kws)``.  Hook functions registered with a transaction are called
-  at the start of a top-level commit, before any of the work is begun, so a
-  hook function can perform any database operations it likes.  See
-  ``test_beforeCommitHook()`` in ``transaction/tests/test_transaction.py``
-  for a tutorial doctest, and the ``ITransaction`` interface for details.
-  Thanks to Florent Guillaume for contributing code and tests.
-
-- (3.4a3) Clarifications were made to transaction interfaces.
-
-Support for ZODB4 savepoint-aware data managers has been dropped
-----------------------------------------------------------------
-
-- (3.4a4) In adding savepoint support, we dropped the attempted support for
-  ZODB4 data managers that support savepoints.  We don't think that this will
-  affect anyone.
-
-ZEO
----
-
-- (3.4a4) The ZODB and ZEO version numbers are now the same.  Concretely::
-
-      import ZODB, ZEO
-      assert ZODB.__version__ == ZEO.version
-
-  no longer fails.  If interested, see the README file for details about
-  earlier version numbering schemes.
-
-- (3.4b1) ZConfig version 2.3 adds new socket address types, for smoother
-  default behavior across platforms.  The hostname portion of
-  socket-binding-address defaults to an empty string, which acts like
-  INADDR_ANY on Windows and Linux (bind to any interface).  The hostname
-  portion of socket-connection-address defaults to "127.0.0.1" (aka
-  "localhost").  In config files, the types of ``zeo`` section keys
-  ``address`` and ``monitor-address`` changed to socket-binding-address,
-  and the type of the ``zeoclient`` section key ``server`` changed to
-  socket-connection-address.
-
-- (3.4a4) The default logging setup in ``runzeo.py`` was broken.  It was
-  changed so that running ``runzeo.py`` from a command line now, and without
-  using a config file, prints output to the console much as ZODB 3.2 did.
-
-ZEO on Windows
---------------
-
-Thanks to Mark Hammond for these ``runzeo.py`` enhancements on Windows:
-
-- (3.4b1) Collector 1788:  Repair one of the new features below.
-
-- (3.4a4) A pid file (containing the process id as a decimal string) is
-  created now for a ZEO server started via ``runzeo.py``.  External programs
-  can read the pid from this file and derive a "signal name" used in a new
-  signal-emulation scheme for Windows.  This is only necessary on Windows,
-  but the pid file is created on all platforms that implement
-  ``os.getpid()``, as long as the ``pid-filename`` option is set, or
-  environment variable ``INSTANCE_HOME`` is defined.  The ``pid-filename``
-  option can be set in a ZEO config file, or passed as the new ``--pid-file``
-  argument to ``runzeo.py``.
-
-- (3.4a4) If available, ``runzeo.py`` now uses Zope's new 'Signal' mechanism
-  for Windows, to implement clean shutdown and log rotation handlers for
-  Windows. Note that the Python in use on the ZEO server must also have the
-  Python Win32 extensions installed for this to be useful.
-
-Tools
------
-
-- (3.4a4) ``fsdump.py`` now displays the size (in bytes) of data records.
-  This actually went in several months go, but wasn't noted here at the time.
-  Thanks to Dmitry Vasiliev for contributing code and tests.
-
-FileStorage
------------
-
-- (3.4a9) The ``undoLog()`` and ``undoInfo()`` methods almost always returned
-  a wrong number of results, one too many if ``last < 0`` (the default is
-  such a case), or one too few if ``last >= 0``.  These have been repaired,
-  new tests were added, and these methods are now documented in
-  ``ZODB.interfaces.IStorageUndoable``.
-
-- (3.4a2) A ``pdb.set_trace()`` call was mistakenly left in method
-  ``FileStorage.modifiedInVersion()``.
-
-ZConfig
--------
-
-- (3.4b1) The "standalone" release of ZODB now includes ZConfig version 2.3.
-
-DemoStorage
------------
-
-- (3.4a4) Appropriate implementations of the storage API's ``registerDB()``
-  and ``new_oid()`` methods were added, delegating to the base storage.  This
-  was needed to support wrapping a ZEO client storage as a ``DemoStorage``
-  base storage, as some new Zope tests want to do.
-
-BaseStorage
------------
-
-- (3.4a4) ``new_oid()``'s undocumented ``last=`` argument was removed.  It
-  was used only for internal recursion, and injured code sanity elsewhere
-  because not all storages included it in their ``new_oid()``'s signature.
-  Straightening this out required adding ``last=`` everywhere, or removing it
-  everywhere. Since recursion isn't actually needed, and there was no other
-  use for ``last=``, removing it everywhere was the obvious choice.
-
-Tests
------
-
-- (3.4a3) The various flavors of the ``check2ZODBThreads`` and
-  ``check7ZODBThreads`` tests are much less likely to suffer sproadic
-  failures now.
-
-- (3.4a2) The test ``checkOldStyleRoot`` failed in Zope3, because of an
-  obscure dependence on the ``Persistence`` package (which Zope3 doesn't use).
-
-ZApplication
-------------
-
-- (3.4a8) The file ``ZApplication.py`` was moved, from ZODB to Zope(2).  ZODB
-  and Zope3 don't use it, but Zope2 does.
-
-- (3.4a7) The ``__call__`` method didn't work if a non-None ``connection``
-  string argument was passed.  Thanks to Stefan Holek for noticing.
-
-
-What's new in ZODB3 3.4a1?
-==========================
-Release date: 01-Apr-2005
-
-transaction
------------
-
-- ``get_transaction()`` is officially deprecated now, and will be removed
-  in ZODB 3.6.  Use the ``transaction`` package instead.   For example,
-  instead of::
-
-      import ZODB
-      ...
-      get_transaction().commit()
-
-  do::
-
-      import transaction
-      ...
-      transaction.commit()
-
-DB
---
-
-- There is no longer a hard limit on the number of connections that
-  ``DB.open()`` will create.  In other words, ``DB.open()`` never blocks
-  anymore waiting for an earlier connection to close, and ``DB.open()``
-  always returns a connection now (while it wasn't documented, it was
-  possible for ``DB.open()`` to return ``None`` before).
-
-  ``pool_size`` continues to default to 7, but its meaning has changed:
-  if more than ``pool_size`` connections are obtained from ``DB.open()``
-  and not closed, a warning is logged; if more than twice ``pool_size``, a
-  critical problem is logged.  ``pool_size`` should be set to the maximum
-  number of connections from the ``DB`` instance you expect to have open
-  simultaneously.
-
-  In addition, if a connection obtained from ``DB.open()`` becomes
-  unreachable without having been explicitly closed, when Python's garbage
-  collection reclaims that connection it no longer counts against the
-  ``pool_size`` thresholds for logging messages.
-
-  The following optional arguments to ``DB.open()`` are deprecated:
-  ``transaction``, ``waitflag``, ``force`` and ``temporary``.  If one
-  is specified, its value is ignored, and ``DeprecationWarning`` is
-  raised.  In ZODB 3.6, these optional arguments will be removed.
-
-- Lightweight support for "multi-databases" is implemented.  These are
-  collections of named DB objects and associated open Connections, such
-  that the Connection for any DB in the collection can be obtained from
-  a Connection from any other DB in the collection.  See the new test
-  file ZODB/tests/multidb.txt for a tutorial doctest.  Thanks to Christian
-  Theune for his work on this during the PyCon 2005 ZODB sprint.
-
-ZEO compatibility
------------------
-
-There are severe restrictions on using ZEO servers and clients at or after
-ZODB 3.3 with ZEO servers and clients from ZODB versions before 3.3.  See the
-reworked ``Compatibility`` section in ``README.txt`` for details.  If
-possible, it will be easiest to move clients and servers to 3.3+
-simultaneously.  With care, it's possible to use a 3.3+ ZEO server with
-pre-3.3 ZEO clients, but not possible to use a pre-3.3 ZEO server with 3.3+
-ZEO clients.
-
-BTrees
-------
-
-- A new family of BTree types, in the ``IFBTree`` module, map
-  signed integers (32 bits) to C floats (also 32 bits).  The
-  intended use is to help construct search indices, where, e.g.,
-  integer word or document identifiers map to scores of some
-  kind.  This is easier than trying to work with scaled integer
-  scores in an ``IIBTree``, and Zope3 has moved to ``IFBTrees``
-  for these purposes in its search code.
-
-FileStorage
------------
-
-- Addded a record iteration protocol to FileStorage.  You can use the
-  record iterator to iterate over all current revisions of data
-  pickles in the storage.
-
-  In order to support calling via ZEO, we don't implement this as an
-  actual iterator.  An example of using the record iterator protocol
-  is as follows::
-
-      storage = FileStorage('anexisting.fs')
-      next_oid = None
-      while True:
-          oid, tid, data, next_oid = storage.record_iternext(next_oid)
-          # do something with oid, tid and data
-          if next_oid is None:
-              break
-
-  The behavior of the iteration protocol is now to iterate over all
-  current records in the database in ascending oid order, although
-  this is not a promise to do so in the future.
-
-
-Tools
------
-
-New tool fsoids.py, for heavy debugging of FileStorages; shows all
-uses of specified oids in the entire database (e.g., suppose oid 0x345620
-is missing -- did it ever exist?  if so, when?  who referenced it?  when
-was the last transaction that modified an object that referenced it?
-which objects did it reference?  what kind of object was it?).
-ZODB/test/testfsoids.py is a tutorial doctest.
-
-
-fsIndex
--------
-
-Efficient, general implementations of ``minKey()`` and ``maxKey()`` methods
-were added.  ``fsIndex`` is a special hybrid kind of BTree used to implement
-FileStorage indices.  Thanks to Chris McDonough for code and tests.
-
-
-What's new in ZODB3 3.3.1?
-==========================
-Release date: DD-MMM-2005
-
-Tests
------
-
-The various flavors of the ``check2ZODBThreads`` and ``check7ZODBThreads``
-tests are much less likely to suffer sproadic failures now.
-
-
-What's new in ZODB3 3.3.1c1?
-============================
-Release date: 01-Apr-2005
-
-BTrees
-------
-
-Collector #1734: BTrees conflict resolution leads to index inconsistencies.
-
-Silent data loss could occur due to BTree conflict resolution when one
-transaction T1 added a new key to a BTree containing at least three buckets,
-and a concurrent transaction T2 deleted all keys in the bucket to which the
-new key was added.  Conflict resolution then created a bucket containing the
-newly added key, but the bucket remained isolated, disconnected from the
-BTree. In other words, the committed BTree didn't contain the new key added by
-T1.  Conflict resolution doesn't have enough information to repair this,
-so ``ConflictError`` is now raised in such cases.
-
-
-ZEO
----
-
-Repaired subtle race conditions in establishing ZEO connections, both client-
-and server-side.  These account for intermittent cases where ZEO failed
-to make a connection (or reconnection), accompanied by a log message showing
-an error caught in ``asyncore`` and having a traceback ending with:
-
-    ``UnpicklingError: invalid load key, 'Z'.``
-
-or:
-
-    ``ZRPCError: bad handshake '(K\x00K\x00U\x0fgetAuthProtocol)t.'``
-
-or:
-
-    ``error: (9, 'Bad file descriptor')``
-
-or an ``AttributeError``.
-
-These were exacerbated when running the test suite, because of an unintended
-busy loop in the test scaffolding, which could starve the thread trying to
-make a connection.  The ZEO reconnection tests may run much faster now,
-depending on platform, and should suffer far fewer (if any) intermittent
-"timed out waiting for storage to connect" failures.
-
-ZEO protocol and compatibility
-------------------------------
-
-ZODB 3.3 introduced multiversion concurrency control (MVCC), which required
-changes to the ZEO protocol.  The first 3.3 release should have increased
-the internal ZEO protocol version number (used by ZEO protocol negotiation
-when a client connects), but neglected to.  This has been repaired.
-
-Compatibility between pre-3.3 and post-3.3 ZEO clients and servers remains
-very limited.  See the newly updated ``Compatibility`` section in
-``README.txt`` for details.
-
-FileStorage
------------
-
-- The ``.store()`` and ``.restore()`` methods didn't update the storage's
-  belief about the largest oid in use when passed an oid larger than the
-  largest oid the storage already knew about.  Because ``.restore()`` in
-  particular is used  by ``copyTransactionsFrom()``, and by the first stage
-  of ZRS recovery, a large database could be created that believed the only
-  oid in use was oid 0 (the special oid reserved for the root object).  In
-  rare cases, it could go on from there assigning duplicate oids to new
-  objects, starting over from oid 1 again.  This has been repaired.  A
-  new ``set_max_oid()`` method was added to the ``BaseStorage`` class so
-  that derived storages can update the largest oid in use in a threadsafe
-  way.
-
-- A FileStorage's index file tried to maintain the index's largest oid as a
-  separate piece of data, incrementally updated over the storage's lifetime.
-  This scheme was more complicated than necessary, so was also more brittle
-  and slower than necessary.  It indirectly participated in a rare but
-  critical bug:  when a FileStorage was created via
-  ``copyTransactionsFrom()``, the "maximum oid" saved in the index file was
-  always 0.  Use that FileStorage, and it could then create "new" oids
-  starting over at 0 again, despite that those oids were already in use by
-  old objects in the database.  Packing a FileStorage has no reason to
-  try to update the maximum oid in the index file either, so this kind of
-  damage could (and did) persist even across packing.
-
-  The index file's maximum-oid data is ignored now, but is still written
-  out so that ``.index`` files can be read by older versions of ZODB.
-  Finding the true maximum oid is done now by exploiting that the main
-  index is really a kind of BTree (long ago, this wasn't true), and finding
-  the largest key in a BTree is inexpensive.
-
-- A FileStorage's index file could be updated on disk even if the storage
-  was opened in read-only mode.  That bug has been repaired.
-
-- An efficient ``maxKey()`` implementation was added to class ``fsIndex``.
-
-
-Pickle (in-memory Connection) Cache
------------------------------------
-
-You probably never saw this exception:
-
-    ``ValueError: Can not re-register object under a different oid``
-
-It's been changed to say what it meant:
-
-    ``ValueError: A different object already has the same oid``
-
-This happens if an attempt is made to add distinct objects to the cache
-that have the same oid (object identifier).  ZODB should never do this,
-but it's possible for application code to force such an attempt.
-
-PersistentMapping and PersistentList
-------------------------------------
-
-Backward compatibility code has been added so that the sanest of the
-ZODB 3.2 dotted paths for ``PersistentMapping`` and ``PersistentList``
-resolve.  These are still preferred:
-
-- ``from persistent.list import PersistentList``
-- ``from persistent.mapping import PersistentMapping``
-
-but these work again too:
-
-- ``from ZODB.PersistentList import PersistentList``
-- ``from ZODB.PersistentMapping import PersistentMapping``
-
-BTrees
-------
-
-The BTrees interface file neglected to document the optional
-``excludemin`` and ``excludemax`` arguments to the ``keys()``, ``values()``
-and ``items()`` methods.  Appropriate changes were merged in from the
-ZODB4 BTrees interface file.
-
-Tools
------
-
-- ``mkzeoinst.py``'s default port number changed from to 9999 to 8100, to
-  match the example in Zope's ``zope.conf``.
-
-fsIndex
--------
-
-An efficient ``maxKey()`` method was implemented for the ``fsIndex`` class.
-This makes it possible to determine the largest oid in a ``FileStorage``
-index efficiently, directly, and reliably, replacing a more delicate scheme
-that tried to keep track of this by saving an oid high water mark in the
-index file and incrementally updating it.
-
-
-What's new in ZODB3 3.3.1a1?
-============================
-Release date: 11-Jan-2005
-
-ZEO client cache
-----------------
-
-- Collector 1536:  The ``cache-size`` configuration option for ZEO clients
-  was being ignored.  Worse, the client cache size was only one megabyte,
-  much smaller than the advertised default of 20MB.  Note that the default
-  is carried over from a time when gigabyte disks were expensive and rare;
-  20MB is also too small on most modern machines.
-
-- Fixed a nasty bug in cache verification.  A persistent ZEO cache uses a
-  disk file, and, when active, has some in-memory data structures too to
-  speed operation.  Invalidations processed as part of startup cache
-  verification were reflected in the in-memory data structures, but not
-  correctly in the disk file.  So if an object revision was invalidated as
-  part of verification, the object wasn't loaded again before the connection
-  was closed, and the object revision remained in the cache file until the
-  connection was closed, then the next time the cache file was opened it
-  could believe that the stale object revision in the file was actually
-  current.
-
-- Fixed a bug wherein an object removed from the client cache didn't
-  properly mark the file slice it occupied as being available for reuse.
-
-ZEO
----
-
-Collector 1503:  excessive logging.  It was possible for a ZEO client to
-log "waiting for cache verification to finish" messages at a very high
-rate, producing gigabytes of such messages in short order.
-``ClientStorage._wait_sync()`` was changed to log no more than one
-such message per 5 minutes.
-
-persistent
-----------
-
-Collector #1350:  ZODB has a default one-thread-per-connection model, and
-two threads should never do operations on a single connection
-simultaneously.  However, ZODB can't detect violations, and this happened
-in an early stage of Zope 2.8 development.  The low-level ``ghostify()``
-and ``unghostify()`` routines in ``cPerisistence.c`` were changed to give
-some help in detecting this when it happens.  In a debug build, both abort
-the process if thread interference is detected.  This is extreme, but
-impossible to overlook.  In a release build, ``unghostify()`` raises
-``SystemError`` if thread damage is detected; ``ghostify()`` ignores the
-problem in a release build (``ghostify()`` is supposed to be so simple that
-it "can't fail").
-
-ConflictError
--------------
-
-New in 3.3, a ``ConflictError`` exception may attempt to insert the path to
-the object's class in its message.  However, a ZEO server may not have
-access to application class implementations, and then the attempt by the
-server to raise ``ConflictError`` could raise ``ImportError`` instead while
-trying to determine the object's class path.  This was confusing.  The code
-has been changed to obtain the class path from the object's pickle, without
-trying to import application modules or classes.
-
-FileStorage
------------
-
-Collector 1581:  When an attempt to pack a corrupted ``Data.fs`` file was
-made, it was possible for the pack routine to die with a reference to an
-undefined global while it was trying to raise ``CorruptedError``.  It
-raises ``CorruptedError``, as it always intended, in these cases now.
-
-Install
--------
-
-The C header file ``ring.h`` is now installed.
-
-Tools
------
-
-- ``BTrees.check.display()`` now displays the oids (if any) of the
-  BTree's or TreeSet's constituent objects.
-
-
-What's new in ZODB3 3.3?
-========================
-Release date: 06-Oct-2004
-
-ZEO
----
-
-The encoding of RPC calls between server and client was being done
-with protocol 0 ("text mode") pickles, which could require sending
-four times as many bytes as necessary.  Protocol 1 pickles are used
-now.  Thanks to Andreas Jung for the diagnosis and cure.
-
-ZODB/component.xml
-------------------
-
-``cache-size`` parameters were changed from type ``integer`` to
-type ``byte-size``.  This allows you to specify, for example,
-"``cache-size 20MB``" to get a 20 megabyte cache.
-
-transaction
------------
-
-The deprecation warning for ``Transaction.begin()`` was changed to
-point to the caller, instead of to ``Transaction.begin()`` itself.
-
-Connection
-----------
-
-Restored Connection's private ``_opened`` attribute.  This was still
-referenced by ``DB.connectionDebugInfo()``, and Zope 2 calls the latter.
-
-FileStorage
------------
-
-Collector #1517: History tab for ZPT does not work. ``FileStorage.history()``
-was reading the user, description, and extension fields out of the object
-pickle, due to starting the read at a wrong location.  Looked like
-cut-and-paste repetition of the same bug in ``FileStorage.FileIterator``
-noted in the news for 3.3c1.
-
-What's new in ZODB3 3.3 release candidate 1?
-============================================
-Release date: 14-Sep-2004
-
-Connection
-----------
-
-ZODB intends to raise ``ConnnectionStateError`` if an attempt is made to
-close a connection while modifications are pending (the connection is
-involved in a transaction that hasn't been ``abort()``'ed or
-``commit()``'ed).  It was missing the case where the only pending
-modifications were made in subtransactions.  This has been fixed.  If an
-attempt to close a connection with pending subtransactions is made now::
-
-    ConnnectionStateError: Cannot close a connection with a pending subtransaction
-
-is raised.
-
-transaction
------------
-
-- Transactions have new, backward-incompatible behavior in one respect:
-  if a ``Transaction.commit()``, ``Transaction.commit(False)``, or
-  ``Transaction.commit(True)`` raised an exception, prior behavior was that
-  the transaction effectively aborted, and a new transaction began.
-  A primary bad consequence was that, if in a sequence of subtransaction
-  commits, one of the commits failed but the exception was suppressed,
-  all changes up to and including the failing commit were lost, but
-  later subtransaction commits in the sequence got no indication that
-  something had gone wrong, nor did the final (top level) commit.  This
-  could easily lead to inconsistent data being committed, from the
-  application's point of view.
-
-  The new behavior is that a failing commit "sticks" until explicitly
-  cleared.  Now if an exception is raised by a ``commit()`` call (whether
-  subtransaction or top level) on a Transaction object ``T``:
-
-    - Pending changes are aborted, exactly as they were for a failing
-      commit before.
-
-    - But ``T`` remains the current transaction object (if ``tm`` is ``T``'s
-      transaction manger, ``tm.get()`` continues to return ``T``).
-
-    - All subsequent attempts to do ``T.commit()``, ``T.join()``, or
-      ``T.register()`` raise the new ``TransactionFailedError`` exception.
-      Note that if you try to modify a persistent object, that object's
-      resource manager (usually a ``Connection`` object) will attempt to
-      ``join()`` the failed transaction, and ``TransactionFailedError``
-      will be raised right away.
-
-  So after a transaction or subtransaction commit fails, that must be
-  explicitly cleared now, either by invoking ``abort()`` on the transaction
-  object, or by invoking ``begin()`` on its transaction manager.
-
-- Some explanations of new transaction features in the 3.3a3 news
-  were incorrect, and this news file has been retroactively edited to
-  repair that.  See news for 3.3a3 below.
-
-- If ReadConflictError was raised by an attempt to load an object with a
-  ``_p_independent()`` method that returned false, attempting to commit the
-  transaction failed to (re)raise ReadConflictError for that object.  Note
-  that ZODB intends to prevent committing a transaction in which a
-  ReadConflictError occurred; this was an obscure case it missed.
-
-- Growing pains:  ZODB 3.2 had a bug wherein ``Transaction.begin()`` didn't
-  abort the current transaction if the only pending changes were in a
-  subtransaction.  In ZODB 3.3, it's intended that a transaction manager be
-  used to effect ``begin()`` (instead of invoking ``Transaction.begin()``),
-  and calling ``begin()`` on a transaction manager didn't have this old
-  bug.  However, ``Transaction.begin()`` still exists in 3.3, and it had a
-  worse bug:  it never aborted the transaction (not even if changes were
-  pending outside of subtransactions). ``Transaction.begin()`` has been
-  changed to abort the transaction. ``Transaction.begin()`` is also
-  deprecated.  Don't use it.  Use ``begin()`` on the relevant transaction
-  manager instead.  For example,
-
-      >>> import transaction
-      >>> txn = transaction.begin()  # start a txn using the default TM
-
-  if using the default ``ThreadTransactionManager`` (see news for 3.3a3
-  below). In 3.3, it's intended that a single ``Transaction`` object is
-  used for exactly one transaction.  So, unlike as in 3.2, when somtimes
-  ``Transaction`` objects were reused across transactions, but sometimes
-  weren't, when you do ``Transaction.begin()`` in 3.3 a brand new
-  transaction object is created.  That's why this use is deprecated.  Code
-  of the form:
-
-      >>> txn = transaction.get()
-      >>> ...
-      >>> txn.begin()
-      >>> ...
-      >>> txn.commit()
-
-  can't work as intended in 3.3, because ``txn`` is no longer the current
-  ``Transaction`` object the instant ``txn.begin()`` returns.
-
-BTrees
-------
-
-The BTrees __init__.py file is now just a comment.  It had been trying
-to set up support for (long gone) "int sets", and to import an old
-version of Zope's Interface package, which doesn't even ship with ZODB.
-The latter in particular created problems, at least clashing with
-PythonCAD's Interface package.
-
-POSException
-------------
-
-Collector #1488 (TemporaryStorage -- going backward in time).  This
-confusion was really due to that the detail on a ConflictError exception
-didn't make sense.  It called the current revision "was", and the old
-revision "now".  The detail is much more informative now.  For example,
-if the exception said::
-
-    ConflictError: database conflict error (oid 0xcb22,
-    serial was 0x03441422948b4399, now 0x034414228c3728d5)
-
-before, it now says::
-
-    ConflictError: database conflict error (oid 0xcb22,
-    serial this txn started with 0x034414228c3728d5 2002-04-14 20:50:32.863000,
-    serial currently committed 0x03441422948b4399 2002-04-14 20:50:34.815000)
-
-ConflictError
--------------
-
-The undocumented ``get_old_serial()`` and ``get_new_serial()`` methods
-were swapped (the first returned the new serial, and the second returned
-the old serial).
-
-Tools
------
-
-``FileStorage.FileIterator`` was confused about how to read a transaction's
-user and description fields, which caused several tools to display
-binary gibberish for these values.
-
-``ZODB.utils.oid_repr()`` changed to add a leading "0x", and to strip
-leading zeroes.  This is used, e.g., in the detail of a ``POSKeyError``
-exception, to identify the missing oid.  Before, the output was ambiguous.
-For example, oid 17 was displayed as 0000000000000011.  As a Python
-integer, that's octal 9.  Or was it meant to be decimal 11?  Or was it
-meant to be hex? Now it displays as 0x11.
-
-fsrefs.py:
-
-    When run with ``-v``, produced tracebacks for objects whose creation was
-    merely undone.  This was confusing.  Tracebacks are now produced only
-    if there's "a real" problem loading an oid.
-
-    If the current revision of object O refers to an object P whose
-    creation has been undone, this is now identified as a distinct case.
-
-    Captured and ignored most attempts to stop it via Ctrl+C.  Repaired.
-
-    Now makes two passes, so that an accurate report can be given of all
-    invalid references.
-
-``analyze.py`` produced spurious "len of unsized object" messages when
-finding a data record for an object uncreation or version abort.  These
-no longer appear.
-
-``fsdump.py``'s ``get_pickle_metadata()`` function (which is used by several
-tools) was confused about what to do when the ZODB pickle started with
-a pickle ``GLOBAL`` opcode.  It actually loaded the class then, which it
-intends never to do, leading to stray messages on stdout when the class
-wasn't available, and leading to a strange return value even when it was
-available (the repr of the type object was returned as "the module name",
-and an empty string was returned as "the class name").  This has been
-repaired.
-
-
-What's new in ZODB3 3.3 beta 2
-==============================
-Release date: 13-Aug-2004
-
-Transaction Managers
---------------------
-
-Zope3-dev Collector #139: Memory leak involving buckets and connections
-
-The transaction manager internals effectively made every Connection
-object immortal, except for those explicitly closed.  Since typical
-practice is not to close connections explicitly (and closing a DB
-happens not to close the connections to it -- although that may
-change), this caused massive memory leaks when many connections were
-opened.  The transaction manager internals were reworked to use weak
-references instead, so that connection memory (and other registered
-synch objects) now get cleaned up when nothing other than the
-transaction manager knows about them.
-
-Storages
---------
-
-Collector #1327: FileStorage init confused by time travel
-
-If the system clock "went backwards" a long time between the times a
-FileStorage was closed and reopened, new transaction ids could be
-smaller than transaction ids already in the storage, violating a
-key invariant.  Now transaction ids are guaranteed to be increasing
-even when this happens.  If time appears to have run backwards at all
-when a FileStorage is opened, a new message saying so is logged at
-warning level; if time appears to have run backwards at least 30
-minutes, the message is logged at critical level (and you should
-investigate to find and repair the true cause).
-
-Tools
------
-
-repozo.py:  Thanks to a suggestion from Toby Dickenson, backups
-(whether incremental or full) are first written to a temp file now,
-which is fsync'ed at the end, and only after that succeeds is the
-file renamed to YYYY-MM-DD-HH-MM-SS.ext form.  In case of a system
-crash during a repozo backup, this at least makes it much less
-likely that a backup file with incomplete or incorrect data will be
-left behind.
-
-fsrefs.py:  Fleshed out the module docstring, and repaired a bug
-wherein spurious error msgs could be produced after reporting a
-problem with an unloadable object.
-
-Test suite
-----------
-
-Collector #1397: testTimeStamp fails on FreeBSD
-
-    The BSD distributions are unique in that their mktime()
-    implementation usually ignores the input tm_isdst value.  Test
-    checkFullTimeStamp() was sensitive to this platform quirk.
-
-Reworked the way some of the ZEO tests use threads, so that unittest is
-more likely to notice the real cause of a failure (which usually occurs in
-a thread), and less likely to latch on to spurious problems resulting from
-the real failure.
-
-
-What's new in ZODB3 3.3 beta 1
-==============================
-Release date: 07-Jun-2004
-
-3.3b1 is the first ZODB release built using the new zpkg tools:
-
-    http://zope.org/Members/fdrake/zpkgtools/
-
-This appears to have worked very well.  The structure of the tarball
-release differs from previous releases because of it, and the set of
-installed files includes some that were not installed in previous
-releases.  That shouldn't create problems, so let us know if it does!
-We'll fine-tune this for the next release.
-
-BTrees
-------
-
-Fixed bug indexing BTreeItems objects with negative indexes.  This
-caused reverse iteration to return each item twice.  Thanks to Casey
-Duncan for the fix.
-
-ZODB
-----
-
-Methods removed from the database (ZODB.DB.DB) class:  cacheStatistics(),
-cacheMeanAge(), cacheMeanDeac(), and cacheMeanDeal().  These were
-undocumented, untested, and unused.  The first always returned an empty
-tuple, and the rest always returned None.
-
-When trying to do recovery to a time earlier than that of the most recent
-full backup, repozo.py failed to find the appropriate files, erroneously
-claiming "No files in repository before <specified time>".  This has
-been repaired.
-
-Collector #1330:  repozo.py -R can create corrupt .fs.
-When looking for the backup files needed to recreate a Data.fs file,
-repozo could (unintentionally) include its meta .dat files in the list,
-or random files of any kind created by the user in the backup directory.
-These would then get copied verbatim into the reconstructed file, filling
-parts with junk.  Repaired by filtering the file list to include only
-files with the data extensions repozo.py creates (.fs, .fsz, .deltafs,
-and .deltafsz).  Thanks to James Henderson for the diagnosis.
-
-fsrecover.py couldn't work, because it referenced attributes that no
-longer existed after the MVCC changes.  Repaired that, and added new
-tests to ensure it continues working.
-
-Collector #1309:  The reference counts reported by DB.cacheExtremeDetails()
-for ghosts were one too small.  Thanks to Dieter Maurer for the diagnosis.
-
-Collector #1208:  Infinite loop in cPickleCache.
-If a persistent object had a __del__ method (probably not a good idea
-regardless, but we don't prevent it) that referenced an attribute of
-self, the code to deactivate objects in the cache could get into an
-infinite loop:  ghostifying the object could lead to calling its __del__
-method, the latter would load the object into cache again to
-satsify the attribute reference, the cache would again decide that
-the object should be ghostified, and so on.  The infinite loop no longer
-occurs, but note that objects of this kind still aren't sensible (they're
-effectively immortal).  Thanks to Toby Dickenson for suggesting a nice
-cure.
-
-
-What's new in ZODB3 3.3 alpha 3
-===============================
-Release date: 16-Apr-2004
-
-transaction
------------
-
-There is a new transaction package, which provides new interfaces for
-application code and for the interaction between transactions and
-resource managers.
-
-The top-level transaction package has functions ``commit()``, ``abort()``,
-``get()``, and ``begin()``.  They should be used instead of the magic
-``get_transaction()`` builtin, which will be deprecated.  For example:
-
-    >>> get_transaction().commit()
-
-should now be written as
-
-    >>> import transaction
-    >>> transaction.commit()
-
-The new API provides explicit transaction manager objects.  A transaction
-manager (TM) is responsible for associating resource managers with a
-"current" transaction.  The default TM, implemented by class
-``ThreadedTransactionManager``, assigns each thread its own current
-transaction.  This default TM is available as ``transaction.manager``.  The
-``TransactionManager`` class assigns all threads to the same transaction,
-and is an explicit replacement for the ``Connection.setLocalTransaction()``
-method:
-
-A transaction manager instance can be passed as the transaction_manager
-argument to ``DB.open()``.  If you do, the connection will use the specified
-transaction manager instead of the default TM.  The current transaction is
-obtained by calling ``get()`` on a TM. For example:
-
-    >>> tm = transaction.TransactionManager()
-    >>> cn = db.open(transaction_manager=tm)
-    [...]
-    >>> tm.get().commit()
-
-The ``setLocalTransaction()`` and ``getTransaction()`` methods of
-Connection are deprecated.  Use an explicit TM passed via
-``transaction_manager=`` to ``DB.open()`` instead.  The
-``setLocalTransaction()`` method still works, but it returns a TM instead of
-a Transaction.
-
-A TM creates Transaction objects, which are used for exactly one
-transaction.  Transaction objects still have ``commit()``, ``abort()``,
-``note()``, ``setUser()``, and ``setExtendedInfo()`` methods.
-
-Resource managers, e.g. Connection or RDB adapter, should use a
-Transaction's ``join()`` method instead of its ``register()`` method.  An
-object that calls ``join()`` manages its own resources.  An object that
-calls ``register()`` expects the TM to manage the objects.
-
-Data managers written against the ZODB 4 transaction API are now
-supported in ZODB 3.
-
-persistent
-----------
-
-A database can now contain persistent weak references.  An object that
-is only reachable from persistent weak references will be removed by
-pack().
-
-The persistence API now distinguishes between deactivation and
-invalidation.  This change is intended to support objects that can't
-be ghosts, like persistent classes.  Deactivation occurs when a user
-calls _p_deactivate() or when the cache evicts objects because it is
-full.  Invalidation occurs when a transaction updates the object.  An
-object that can't be a ghost must load new state when it is
-invalidated, but can ignore deactivation.
-
-Persistent objects can implement a __getnewargs__() method that will
-be used to provide arguments that should be passed to __new__() when
-instances (including ghosts) are created.  An object that implements
-__getnewargs__() must be loaded from storage even to create a ghost.
-
-There is new support for writing hooks like __getattr__ and
-__getattribute__.  The new hooks require that user code call special
-persistence methods like _p_getattr() inside their hook.  See the ZODB
-programming guide for details.
-
-The format of serialized persistent references has changed; that is,
-the on-disk format for references has changed.  The old format is
-still supported, but earlier versions of ZODB will not be able to read
-the new format.
-
-ZODB
-----
-
-Closing a ZODB Connection while it is registered with a transaction,
-e.g. has pending modifications, will raise a ConnnectionStateError.
-Trying to load objects from or store objects to a closed connection
-will also raise a ConnnectionStateError.
-
-ZODB connections are synchronized on commit, even when they didn't
-modify objects.  This feature assumes that the thread that opened the
-connection is also the thread that uses it.  If not, this feature will
-cause problems.  It can be disabled by passing synch=False to open().
-
-New broken object support.
-
-New add() method on Connection.  User code should not assign the
-_p_jar attribute of a new persistent object directly; a deprecation
-warning is issued in this case.
-
-Added a get() method to Connection as a preferred synonym for
-__getitem__().
-
-Several methods and/or specific optional arguments of methods have
-been deprecated.  The cache_deactivate_after argument used by DB() and
-Connection() is deprecated.  The DB methods getCacheDeactivateAfter(),
-getVersionCacheDeactivateAfter(), setCacheDeactivateAfter(), and
-setVersionCacheDeactivateAfter() are also deprecated.
-
-The old-style undo() method was removed from the storage API, and
-transactionalUndo() was renamed to undo().
-
-The BDBStorages are no longer distributed with ZODB.
-
-Fixed a serious bug in the new pack implementation.  If pack was
-called on the storage and passed a time earlier than a previous pack
-time, data could be lost.  In other words, if there are any two pack
-calls, where the time argument passed to the second call was earlier
-than the first call, data loss could occur.  The bug was fixed by
-causing the second call to raise a StorageError before performing any
-work.
-
-Fixed a rare bug in pack:  if a pack started during a small window of
-time near the end of a concurrent transaction's commit, it was possible
-for the pack attempt to raise a spurious
-
-     CorruptedError: ... transaction with checkpoint flag set
-
-exception.  This did no damage to the database, or to the transaction
-in progress, but no pack was performed then.
-
-By popular demand, FileStorage.pack() no longer propagates a
-
-    FileStorageError:  The database has already been packed to a
-    later time or no changes have been made since the last pack
-
-exception.  Instead that message is logged (at INFO level), and
-the pack attempt simply returns then (no pack is performed).
-
-ZEO
----
-
-Fixed a bug that prevented the -m / --monitor argument from working.
-
-zdaemon
--------
-
-Added a -m / --mask option that controls the umask of the subprocess.
-
-zLOG
-----
-
-The zLOG backend has been removed.  zLOG is now just a facade over the
-standard Python logging package.  Environment variables like
-STUPID_LOG_FILE are no longer honored.  To configure logging, you need
-to follow the directions in the logging package documentation.  The
-process is currently more complicated than configured zLOG.  See
-test.py for an example.
-
-ZConfig
--------
-
-This release of ZODB contains ZConfig 2.1.
-
-More documentation has been written.
-
-Make sure keys specified as attributes of the <default> element are
-converted by the appropriate key type, and are re-checked for derived
-sections.
-
-Refactored the ZConfig.components.logger schema components so that a
-schema can import just one of the "eventlog" or "logger" sections if
-desired.  This can be helpful to avoid naming conflicts.
-
-Added a reopen() method to the logger factories.
-
-Always use an absolute pathname when opening a FileHandler.
-
-
-Miscellaneous
--------------
-
-The layout of the ZODB source release has changed.  All the source
-code is contained in a src subdirectory.  The primary motivation for
-this change was to avoid confusion caused by installing ZODB and then
-testing it interactively from the source directory; the interpreter
-would find the uncompiled ZODB package in the source directory and
-report an import error.
-
-A reference-counting bug was fixed, in the logic calling a modified
-persistent object's data manager's register() method.  The primary symptom
-was rare assertion failures in Python's cyclic garbage collection.
-
-The Connection class's onCommitAction() method was removed.
-
-Some of the doc strings in ZODB are now written for processing by
-epydoc.
-
-Several new test suites were written using doctest instead of the
-standard unittest TestCase framework.
-
-MappingStorage now implements getTid().
-
-ThreadedAsync: Provide a way to shutdown the servers using an exit
-status.
-
-The mkzeoinstance script looks for a ZODB installation, not a Zope
-installation.  The received wisdom is that running a ZEO server
-without access to the appserver code avoids many mysterious problems.
-
-
-What's new in ZODB3 3.3 alpha 2
-===============================
-Release date: 06-Jan-2004
-
-This release contains a major overhaul of the persistence machinery,
-including some user-visible changes.  The Persistent base class is now
-a new-style class instead of an ExtensionClass.  The change enables
-the use of features like properties with persistent object classes.
-The Persistent base class is now contained in the persistent package.
-
-The Persistence package is included for backwards compatibility.  The
-Persistence package is used by Zope to provide special
-ExtensionClass-compatibility features like a non-C3 MRO and an __of__
-method.  ExtensionClass is not included with this release of ZODB3.
-If you use the Persistence package, it will print a warning and import
-Persistent from persistent.
-
-In short, the new persistent package is recommended for non-Zope
-applications.  The following dotted class names are now preferred over
-earlier names:
-
-- persistent.Persistent
-- persistent.list.PersistentList
-- persistent.mapping.PersistentMapping
-- persistent.TimeStamp
-
-The in-memory, per-connection object cache (pickle cache) was changed
-to participate in garbage collection.  This should reduce the number
-of memory leaks, although we are still tracking a few problems.
-
-Multi-version concurrency control
----------------------------------
-
-ZODB now supports multi-version concurrency control (MVCC) for
-storages that support multiple revisions.  FileStorage and
-BDBFullStorage both support MVCC.  In short, MVCC means that read
-conflicts should almost never occur.  When an object is modified in
-one transaction, other concurrent transactions read old revisions of
-the object to preserve consistency.  In earlier versions of ZODB, any
-access of the modified object would raise a ReadConflictError.
-
-The ZODB internals changed significantly to accommodate MVCC.  There
-are relatively few user visible changes, aside from the lack of read
-conflicts.  It is possible to disable the MVCC feature using the mvcc
-keyword argument to the DB open() method, ex.: db.open(mvcc=False).
-
-ZEO
----
-
-Changed the ZEO server and control process to work with a single
-configuration file; this is now the default way to configure these
-processes.  (It's still possible to use separate configuration files.)
-The ZEO configuration file can now include a "runner" section used by
-the control process and ignored by the ZEO server process itself.  If
-present, the control process can use the same configuration file.
-
-Fixed a performance problem in the logging code for the ZEO protocol.
-The logging code could call repr() on arbitrarily long lists, even
-though it only logged the first 60 bytes; worse, it called repr() even
-if logging was currently disabled.  Fixed to call repr() on individual
-elements until the limit is reached.
-
-Fixed a bug in zrpc (when using authentication) where the MAC header
-wasn't being read for large messages, generating errors while unpickling
-commands sent over the wire. Also fixed the zeopasswd.py script, added
-testcases and provided a more complete commandline interface.
-
-Fixed a misuse of the _map variable in zrpc Connectio objects, which
-are also asyncore.dispatcher objects.  This allows ZEO to work with
-CVS Python (2.4). _map is used to indicate whether the dispatcher
-users the default socket_map or a custom socket_map.  A recent change
-to asyncore caused it to use _map in its add_channel() and
-del_channel() methods, which presumes to be a bug fix (may get ported
-to 2.3).  That causes our dubious use of _map to be a problem, because
-we also put the Connections in the global socket_map.  The new
-asyncore won't remove it from the global socket map, because it has a
-custom _map.
-
-The prefix used for log messages from runzeo.py was changed from
-RUNSVR to RUNZEO.
-
-Miscellaneous
--------------
-
-ReadConflictError objects now have an ignore() method.  Normally, a
-transaction that causes a read conflict can't be committed.  If the
-exception is caught and its ignore() method called, the transaction
-can be committed.  Application code may need this in advanced
-applications.
-
-
-What's new in ZODB3 3.3 alpha 1
-===============================
-Release date: 17-Jul-2003
-
-New features of Persistence
----------------------------
-
-The Persistent base class is a regular Python type implemented in C.
-It should be possible to create new-style classes that inherit from
-Persistent, and, thus, use all the new Python features introduced in
-Python 2.2 and 2.3.
-
-The __changed__() method on Persistent objects is no longer supported.
-
-New features in BTrees
-----------------------
-
-BTree, Bucket, TreeSet and Set objects are now iterable objects, playing
-nicely with the iteration protocol introduced in Python 2.2, and can
-be used in any context that accepts an iterable object.  As for Python
-dicts, the iterator constructed for BTrees and Buckets iterates
-over the keys.
-
->>> from BTrees.OOBTree import OOBTree
->>> b = OOBTree({"one": 1, "two": 2, "three": 3, "four": 4})
->>> for key in b: # iterates over the keys
-...    print key
-four
-one
-three
-two
->>> list(enumerate(b))
-[(0, 'four'), (1, 'one'), (2, 'three'), (3, 'two')]
->>> i = iter(b)
->>> i.next()
-'four'
->>> i.next()
-'one'
->>> i.next()
-'three'
->>> i.next()
-'two'
->>>
-
-As for Python dicts in 2.2, BTree and Bucket objects have new
-.iterkeys(), .iteritems(), and .itervalues() methods.  TreeSet and Set
-objects have a new .iterkeys() method.  Unlike as for Python dicts,
-these new methods accept optional min and max arguments to effect
-range searches.  While Bucket.keys() produces a list, Bucket.iterkeys()
-produces an iterator, and similarly for Bucket values() versus
-itervalues(), Bucket items() versus iteritems(), and Set keys() versus
-iterkeys().  The iter{keys,values,items} methods of BTrees and the
-iterkeys() method of Treesets also produce iterators, while their
-keys() (etc) methods continue to produce BTreeItems objects (a form of
-"lazy" iterator that predates Python 2.2's iteration protocol).
-
->>> sum(b.itervalues())
-10
->>> zip(b.itervalues(), b.iterkeys())
-[(4, 'four'), (1, 'one'), (3, 'three'), (2, 'two')]
->>>
-
-BTree, Bucket, TreeSet and Set objects also implement the __contains__
-method new in Python 2.2, which means that testing for key membership
-can be done directly now via the "in" and "not in" operators:
-
->>> "won" in b
-False
->>> "won" not in b
-True
->>> "one" in b
-True
->>>
-
-All old and new range-search methods now accept keyword arguments,
-and new optional excludemin and excludemax keyword arguments.  The
-new keyword arguments allow doing a range search that's exclusive
-at one or both ends (doesn't include min, and/or doesn't include
-max).
-
->>> list(b.keys())
-['four', 'one', 'three', 'two']
->>> list(b.keys(max='three'))
-['four', 'one', 'three']
->>> list(b.keys(max='three', excludemax=True))
-['four', 'one']
->>>
-
-Other improvements
-------------------
-
-The exceptions generated by write conflicts now contain the name of
-the conflicted object's class.  This feature requires support for the
-storage.  All the standard storages support it.
-
-What's new in ZODB3 3.2
-========================
-Release date: 08-Oct-2003
-
-Nothing has changed since release candidate 1.
-
-What's new in ZODB3 3.2 release candidate 1
-===========================================
-Release date: 01-Oct-2003
-
-Added a summary to the Doc directory.  There are several new documents
-in the 3.2 release, including "Using zdctl and zdrun to manage server
-processes" and "Running a ZEO Server HOWTO."
-
-Fixed ZEO's protocol negotiation mechanism so that a client ZODB 3.1
-can talk to a ZODB 3.2 server.
-
-Fixed a memory leak in the ZEO server.  The server was leaking a few
-KB of memory per connection.
-
-Fixed a memory leak in the ZODB object cache (cPickleCache).  The
-cache did not release two references to its Connection, causing a
-large cycle of objects to leak when a database was closed.
-
-Fixed a bug in the ZEO code that caused it to leak socket objects on
-Windows.  Specifically, fix the trigger mechanism so that both sockets
-created for a trigger are closed.
-
-Fixed a bug in the ZEO storage server that caused it to leave temp
-files behind.  The CommitLog class contains a temp file, but it was
-not closing the file.
-
-Changed the order of setuid() and setgid() calls in zdrun, so that
-setgid() is called first.
-
-Added a timeout to the ZEO test suite that prevents hangs.  The test
-suite creates ZEO servers with randomly assigned ports.  If the port
-happens to be in use, the test suite would hang because the ZEO client
-would never stop trying to connect.  The fix will cause the test to
-fail after a minute, but should prevent the test runner from hanging.
-
-The logging package was updated to include the latest version of the
-logging package from Python CVS.  Note that this package is only
-installed for Python 2.2.  In later versions of Python, it is
-available in the Python standard library.
-
-The ZEO1 directory was removed from the source distribution.  ZEO1 is
-not supported, and we never intended to include it in the release.
-
-What's new in ZODB3 3.2 beta 3
-==============================
-Release date: 23-Sep-2003
-
-Note: The changes listed for this release include changes also made in
-ZODB 3.1.x releases and ported to the 3.2 release.
-
-This version of ZODB 3.2 is not compatible with Python 2.1.  Early
-versions were explicitly designed to be compatible with Zope 2.6.
-That plan has been dropped, because Zope 2.7 is already in beta
-release.
-
-Several of the classes in ZEO and ZODB now inherit from object, making
-them new-style classes.  The primary motivation for the change was to
-make it easier to debug memory leaks.  We don't expect any behavior to
-change as a result.
-
-A new feature to allow removal of connection pools for versions was
-ported from Zope 2.6.  This feature is needed by Zope to avoid denial
-of service attacks that allow a client to create an arbitrary number
-of version pools.
-
-Fixed several critical ZEO bugs.
-
-- If several client transactions were blocked waiting for the storage
-  and one of the blocked clients disconnected, the server would
-  attempt to restart one of the other waiting clients.  Since the
-  disconnected client did not have the storage lock, this could lead
-  to deadlock.  It could also cause the assertion "self._client is
-  None" to fail.
-
-- If a storage server fails or times out between the vote and the
-  finish, the ZEO cache could get populated with objects that didn't
-  make it to the storage server.
-
-- If a client loses its connection to the server near the end of a
-  transaction, it is now guaranteed to get a ClientDisconnected error
-  even if it reconnects before the transaction finishes.  This is
-  necessary because the server will always abort the transaction.
-  In some cases, the client would never see an error for the aborted
-  transaction.
-
-- In tpc_finish(), reordered the calls so that the server's tpc_finish()
-  is called (and must succeed) before we update the ZEO client cache.
-
-- The storage name is now prepended to the sort key, to ensure a
-  unique global sort order if storages are named uniquely.  This
-  can prevent deadlock in some unusual cases.
-
-Fixed several serious flaws in the implementation of the ZEO
-authentication protocol.
-
-- The smac layer would accept a message without a MAC even after the
-  session key was established.
-
-- The client never initialized its session key, so it never checked
-  incoming messages or created MACs for outgoing messags.
-
-- The smac layer used a single HMAC instance for sending and receiving
-  messages.  This approach could only work if client and server were
-  guaranteed to process all messages in the same total order, which
-  could only happen in simple scenarios like unit tests.
-
-Fixed a bug in ExtensionClass when comparing ExtensionClass instances.
-The code could raise RuntimeWarning under Python 2.3, and produce
-incorrect results on 64-bit platforms.
-
-Fixed bug in BDBStorage that could lead to DBRunRecoveryErrors when a
-transaction was aborted after performing operations like commit
-version or undo that create new references to existing pickles.
-
-Fixed a bug in Connection.py that caused it to fail with an
-AttributeError if close() was called after the database was closed.
-
-The test suite leaves fewer log files behind, although it still leaves
-a lot of junk.  The test.py script puts each tests temp files in a
-separate directory, so it is easier to see which tests are causing
-problems.  Unfortunately, it is still to tedious to figure out why the
-identified tests are leaving files behind.
-
-This release contains the latest and greatest version of the
-BDBStorage.  This storage has still not seen testing in a production
-environment, but it represents the current best design and most recent
-code culled from various branches where development has occurred.
-
-The Tools directory contains a number of small improvements, a few new
-tools, and README.txt that catalogs the tools.  Many of the tools are
-installed by setup.py; those scripts will now have a #! line set
-automatically on Unix.
-
-Fixed bugs in Tools/repozo.py, including a timing-dependent one that
-could cause the following invocation of repozo to do a full backup when
-an incremental backup would have sufficed.
-
-A pair of new scripts from Jim Fulton can be used to synthesize
-workloads and measure ZEO performance:  see zodbload.py and
-zeoserverlog.py in the Tools directory.  Note that these require
-Zope.
-
-Tools/checkbtrees.py was strengthened in two ways:
-
-- In addition to running the _check() method on each BTree B found,
-  BTrees.check.check(B) is also run.  The check() function was written
-  after checkbtrees.py, and identifies kinds of damage B._check()
-  cannot find.
-
-- Cycles in the object graph no longer lead to unbounded output.
-  Note that preventing this requires remembering the oid of each
-  persistent object found, which increases the memory needed by the
-  script.
-
-What's new in ZODB3 3.2 beta 2
-==============================
-Release date: 16-Jun-2003
-
-Fixed critical race conditions in ZEO's cache consistency code that
-could cause invalidations to be lost or stale data to be written to
-the cache.  These bugs can lead to data loss or data corruption.
-These bugs are relatively unlikely to be provoked in sites with few
-conflicts, but the possibility of failure existed any time an object
-was loaded and stored concurrently.
-
-Fixed a bug in conflict resolution that failed to ghostify an object
-if it was involved in a conflict.  (This code may be redundant, but it
-has been fixed regardless.)
-
-The ZEO server was fixed so that it does not perform any I/O until all
-of a transactions' invalidations are queued.  If it performs I/O in the
-middle of sending invalidations, it would be possible to overlap a
-load from a client with the invalidation being sent to it.
-
-The ZEO cache now handles invalidations atomically.  This is the same
-sort of bug that is described in the 3.1.2b1 section below, but it
-affects the ZEO cache.
-
-Fixed several serious bugs in fsrecover that caused it to fail
-catastrophically in certain cases because it thought it had found a
-checkpoint (status "c") record when it was in the middle of the file.
-
-Two new features snuck into this beta release.
-
-The ZODB.transact module provides a helper function that converts a
-regular function or method into a transactional one.
-
-The ZEO client cache now supports Adaptable Persistence (APE).  The
-cache used to expect that all OIDs were eight bytes long.
-
-What's new in ZODB3 3.2 beta 1
-==============================
-Release date: 30-May-2003
-
-ZODB
-----
-
-Invalidations are now processed atomically.  Each transaction will see
-all the changes caused by an earlier transaction or none of them.
-Before this patch, it was possible for a transaction to see invalid
-data because it saw only a subset of the invalidations.  This is the
-most likely cause of reported BTrees corruption, where keys were
-stored in the wrong bucket.  When a BTree bucket splits, the bucket
-and the bucket's parent are both modified.  If a transaction sees the
-invalidation for the bucket but not the parent, the BTree in memory
-will be internally inconsistent and keys can be put in the wrong
-bucket.  The atomic invalidation fix prevents this problem.
-
-A number of minor reference count fixes in the object cache were
-fixed.  That's the cPickleCache.c file.
-
-It was possible for a transaction that failed in tpc_finish() to lose
-the traceback that caused the failure.  The transaction code was fixed
-to report the original error as well as any errors that occur while
-trying to recover from the original error.
-
-The "other" argument to copyTransactionsFrom() only needs to have an
-.iterator() method.  For convenience, change FileStorage's and
-BDBFullStorage's iterator to have this method, which just returns
-self.
-
-Mount points are now visible from mounted objects.
-
-Fixed memory leak involving database connections and caches.  When a
-connection or database was closed, the cache and database leaked,
-because of a circular reference involving the cache.  Fixed the cache
-to explicitly clear out its contents when its connection is closed.
-
-The ZODB cache has fewer methods.  It used to expose methods that
-could mutate the dictionary, which allowed users to violate internal
-invariants.
-
-ZConfig
--------
-
-It is now possible to configure ZODB databases and storages and ZEO
-servers using ZConfig.
-
-ZEO & zdaemon
--------------
-
-ZEO now supports authenticated client connections.  The default
-authentication protocol uses a hash-based challenge-response protocol
-to prove identity and establish a session key for message
-authentication.  The architecture is pluggable to allow third-parties
-to developer better authentication protocols.
-
-There is a new HOWTO for running a ZEO server.  The draft in this
-release is incomplete, but provides more guidance than previous
-releases.  See the file Doc/ZEO/howto.txt.
-
-
-The ZEO storage server's transaction timeout feature was refactored
-and made slightly more rebust.
-
-A new ZEO utility script, ZEO/mkzeoinst.py, was added.  This creates a
-standard directory structure and writes a configuration file with
-mostly default values, and a bootstrap script that can be used to
-manage and monitor the server using zdctl.py (see below).
-
-Much work was done to improve zdaemon's zdctl.py and zdrun.py scripts.
-(In the alpha 1 release, zdrun.py was called zdaemon.py, but
-installing it in <prefix>/bin caused much breakage due to the name
-conflict with the zdaemon package.)  Together with the new
-mkzeoinst.py script, this makes controlling a ZEO server a breeze.
-
-A ZEO client will not read from its cache during cache verification.
-This fix was necessary to prevent the client from reading inconsistent
-data.
-
-The isReadOnly() method of a ZEO client was fixed to return the false
-when the client is connected to a read-only fallback server.
-
-The sync() method of ClientStorage and the pending() method of a zrpc
-connection now do both input and output.
-
-The short_repr() function used to generate log messages was fixed so
-that it does not blow up creating a repr of very long tuples.
-
-Storages
---------
-
-FileStorage has a new pack() implementation that fixes several
-reported problems that could lead to data loss.
-
-Two small bugs were fixed in DemoStorage.  undoLog() did not handle
-its arguments correctly and pack() could accidentally delete objects
-created in versions.
-
-Fixed trivial bug in fsrecover that prevented it from working at all.
-
-FileStorage will use fsync() on Windows starting with Python 2.2.3.
-
-FileStorage's commit version was fixed.  It used to stop after the
-first object, leaving all the other objects in the version.
-
-BTrees
-------
-
-Trying to store an object of a non-integer type into an IIBTree
-or OIBTree could leave the bucket in a variety of insane states.  For
-example, trying
-
-    b[obj] = "I'm a string, not an integer"
-
-where b is an OIBTree.  This manifested as a refcount leak in the test
-suite, but could have been much worse (most likely in real life is that
-a seemingly arbitrary existing key would "go missing").
-
-When deleting the first child of a BTree node with more than one
-child, a reference to the second child leaked.  This could cause
-the entire bucket chain to leak (not be collected as garbage
-despite not being referenced anymore).
-
-Other minor BTree leak scenarios were also fixed.
-
-Tools
------
-
-New tool zeoqueue.py for parsing ZEO log files, looking for blocked
-transactions.
-
-New tool repozo.py (originally by Anthony Baxter) for performing
-incremental backups of Data.fs files.
-
-The fsrecover.py script now does a better job of recovering from
-errors the occur in the middle of a transaction record.  Fixed several
-bugs that caused partial or total failures in earlier versions.
-
-
-What's new in ZODB3 3.2 alpha 1
-===============================
-Release date: 17-Jan-2003
-
-Most of the changes in this release are performance and stability
-improvements to ZEO.  A major packaging change is that there won't be
-a separate ZEO release.  The new ZConfig is a noteworthy addtion (see
-below).
-
-ZODB
-----
-
-An experimental new transaction API was added.  The Connection class
-has a new method, setLocalTransaction().  ZODB applications can call
-this method to bind transactions to connections rather than threads.
-This is especially useful for GUI applications, which often have only
-one thread but multiple independent activities within that thread
-(generally one per window).  Thanks to Christian Reis for championing
-this feature.
-
-Applications that take advantage of this feature should not use the
-get_transaction() function.  Until now, ZODB itself sometimes assumed
-get_transaction() was the only way to get the transaction.  Minor
-corrections have been added.  The ZODB test suite, on the other hand,
-can continue to use get_transaction(), since it is free to assume that
-transactions are bound to threads.
-
-ZEO
----
-
-There is a new recommended script for starting a storage server.  We
-recommend using ZEO/runzeo.py instead of ZEO/start.py.  The start.py
-script is still available in this release, but it will no longer be
-maintained and will eventually be removed.
-
-There is a new zdaemon implementation.  This version is a separate
-script that runs an arbitrary daemon.  To run the ZEO server as a
-daemon, you would run "zdrun.py runzeo.py".  There is also a simple
-shell, zdctl.py, that can be used to manage a daemon.  Try
-"zdctl.py -p runzeo.py".
-
-There is a new version of the ZEO protocol in this release and a first
-stab at protocol negotiation.  (It's a first stab because the protocol
-checking supporting in ZODB 3.1 was too primitive to support anything
-better.)  A ZODB 3.2 ZEO client can talk to an old server, but a ZODB
-3.2 server can't talk to an old client.  It's safe to upgrade all the
-clients first and upgrade the server last.  The ZEO client cache
-format changed, so you'll need to delete persistent caches before
-restarting clients.
-
-The ZEO cache verification protocol was revised to require many fewer
-messages in cases where a client or server restarts quickly.
-
-The performance of full cache verification has improved dramatically.
-Measurements from Jim were somewhere in 2x-5x.  The
-implementation was fixed to use the very-fast getSerial() method on
-the storage instead of the comparatively slow load().
-
-The ZEO server has an optional timeout feature that will abort a
-connection that does not commit within a certain amount of time.  The
-timeout works by closing the socket the client is using, causing both
-client and server to abort the transaction and continue.  This is a
-drastic step, but can be useful to prevent a hung client or other bug
-from blocking a server indefinitely.
-
-A bug was fixed in the ZEO protocol that allowed clients to read stale
-cache data while cache verification was being performed.  The fixed
-version prevents the client from using the storage until after
-verification completes.
-
-The ZEO server has an experimental monitoring interface that reports
-usage statistics for the storage server including number of connected
-clients and number of transactions active and committed.  It can be
-enabled by passing the -m flag to runsvr.py.
-
-The ZEO ClientStorage no longer supports the environment variables
-CLIENT_HOME, INSTANCE_HOME, or ZEO_CLIENT.
-
-The ZEO1 package is still included with this release, but there is no
-longer an option to install it.
-
-BTrees
-------
-
-The BTrees package now has a check module that inspects a BTree to
-check internal invariants.  Bugs in older versions of the code code
-leave a BTree in an inconsistent state.  Calling BTrees.check.check()
-on a BTree object should verify its consistency.  (See the NEWS
-section for 3.1 beta 1 below to for the old BTrees bugs.)
-
-Fixed a rare conflict resolution problem in the BTrees that could
-cause an segfault when the conflict resolution resulted in any
-empty bucket.
-
-Installation
-------------
-
-The distutils setup now installs several Python scripts.  The
-runzeo.py and zdrun.py scripts mentioned above and several fsXXX.py
-scripts from the Tools directory.
-
-The test.py script does not run all the ZEO tests by default, because
-the ZEO tests take a long time to run.  Use --all to run all the
-tests.  Otherwise a subset of the tests, mostly using MappingStorage,
-are run.
-
-Storages
---------
-
-There are two new storages based on Sleepycat's BerkeleyDB in the
-BDBStorage package.  Barry will have to write more here, because I
-don't know how different they are from the old bsddb3Storage
-storages.  See Doc/BDBStorage.txt for more information.
-
-It now takes less time to open an existing FileStorage.  The
-FileStorage uses a BTree-based index that is faster to pickle and
-unpickle.  It also saves the index periodically so that subsequent
-opens will go fast even if the storage was not closed cleanly.
-
-Misc
-----
-
-The new ZConfig package, which will be used by Zope and ZODB, is
-included.  ZConfig provides a configuration syntax, similar to
-Apache's syntax.  The package can be used to configure the ZEO server
-and ZODB databases.  See the module ZODB.config for functions to open
-the database from configuration.  See ZConfig/doc for more info.
-
-The zLOG package now uses the logging package by Vinay Sajip, which
-will be included in Python 2.3.
-
-The Sync extension was removed from ExtensionClass, because it was not
-used by ZODB.
-
-What's new in ZODB3 3.1.4?
-==========================
-Release date: 11-Sep-2003
-
-A new feature to allow removal of connection pools for versions was
-ported from Zope 2.6.  This feature is needed by Zope to avoid denial
-of service attacks that allow a client to create an arbitrary number
-of version pools.
-
-A pair of new scripts from Jim Fulton can be used to synthesize
-workloads and measure ZEO performance:  see zodbload.py and
-zeoserverlog.py in the Tools directory.  Note that these require
-Zope.
-
-Tools/checkbtrees.py was strengthened in two ways:
-
-- In addition to running the _check() method on each BTree B found,
-  BTrees.check.check(B) is also run.  The check() function was written
-  after checkbtrees.py, and identifies kinds of damage B._check()
-  cannot find.
-
-- Cycles in the object graph no longer lead to unbounded output.
-  Note that preventing this requires remembering the oid of each
-  persistent object found, which increases the memory needed by the
-  script.
-
-What's new in ZODB3 3.1.3?
-==========================
-Release date: 18-Aug-2003
-
-Fixed several critical ZEO bugs.
-
-- If a storage server fails or times out between the vote and the
-  finish, the ZEO cache could get populated with objects that didn't
-  make it to the storage server.
-
-- If a client loses its connection to the server near the end of a
-  transaction, it is now guaranteed to get a ClientDisconnected error
-  even if it reconnects before the transaction finishes.  This is
-  necessary because the server will always abort the transaction.
-  In some cases, the client would never see an error for the aborted
-  transaction.
-
-- In tpc_finish(), reordered the calls so that the server's tpc_finish()
-  is called (and must succeed) before we update the ZEO client cache.
-
-- The storage name is now prepended to the sort key, to ensure a
-  unique global sort order if storages are named uniquely.  This
-  can prevent deadlock in some unusual cases.
-
-A variety of fixes and improvements to Berkeley storage (aka BDBStorage)
-were back-ported from ZODB 4.  This release now contains the most
-current version of the Berkeley storage code.  Many tests have been
-back-ported, but not all.
-
-Modified the Windows tests to wait longer at the end of ZEO tests for
-the server to shut down.  Before Python 2.3, there is no waitpid() on
-Windows, and, thus, no way to know if the server has shut down.  The
-change makes the Windows ZEO tests much less likely to fail or hang,
-at the cost of increasing the time needed to run the tests.
-
-Fixed a bug in ExtensionClass when comparing ExtensionClass instances.
-The code could raise RuntimeWarning under Python 2.3, and produce
-incorrect results on 64-bit platforms.
-
-Fixed bugs in Tools/repozo.py, including a timing-dependent one that
-could cause the following invocation of repozo to do a full backup when
-an incremental backup would have sufficed.
-
-Added Tools/README.txt that explains what each of the scripts in the
-Tools directory does.
-
-There were many small changes and improvements to the test suite.
-
-What's new in ZODB3 3.1.2 final?
-================================
-
-Fixed bug in FileStorage pack that caused it to fail if it encountered
-an old undo record (status "u").
-
-Fixed several bugs in FileStorage pack that could cause OverflowErrors
-for storages > 2 GB.
-
-Fixed memory leak in TimeStamp.laterThan() that only occurred when it
-had to create a new TimeStamp.
-
-Fixed two BTree bugs that were fixed on the head a while ago:
-
-   - bug in fsBTree that would cause byValue searches to end early.
-     (fsBTrees are never used this way, but it was still a bug.)
-
-   -  bug that lead to segfault if BTree was mutated via deletion
-      while it was being iterated over.
-
-What's new in ZODB3 3.1.2 beta 2?
-=================================
-
-Fixed critical race conditions in ZEO's cache consistency code that
-could cause invalidations to be lost or stale data to be written to
-the cache.  These bugs can lead to data loss or data corruption.
-These bugs are relatively unlikely to be provoked in sites with few
-conflicts, but the possibility of failure existed any time an object
-was loaded and stored concurrently.
-
-Fixed a bug in conflict resolution that failed to ghostify an object
-if it was involved in a conflict.  (This code may be redundant, but it
-has been fixed regardless.)
-
-The ZEO server was fixed so that it does not perform any I/O until all
-of a transactions' invalidations are queued.  If it performs I/O in the
-middle of sending invalidations, it would be possible to overlap a
-load from a client with the invalidation being sent to it.
-
-The ZEO cache now handles invalidations atomically.  This is the same
-sort of bug that is described in the 3.1.2b1 section below, but it
-affects the ZEO cache.
-
-Fixed several serious bugs in fsrecover that caused it to fail
-catastrophically in certain cases because it thought it had found a
-checkpoint (status "c") record when it was in the middle of the file.
-
-What's new in ZODB3 3.1.2 beta 1?
-=================================
-
-ZODB
-----
-
-Invalidations are now processed atomically.  Each transaction will see
-all the changes caused by an earlier transaction or none of them.
-Before this patch, it was possible for a transaction to see invalid
-data because it saw only a subset of the invalidations.  This is the
-most likely cause of reported BTrees corruption, where keys were
-stored in the wrong bucket.  When a BTree bucket splits, the bucket
-and the bucket's parent are both modified.  If a transaction sees the
-invalidation for the bucket but not the parent, the BTree in memory
-will be internally inconsistent and keys can be put in the wrong
-bucket.  The atomic invalidation fix prevents this problem.
-
-A number of minor reference count fixes in the object cache were
-fixed.  That's the cPickleCache.c file.
-
-It was possible for a transaction that failed in tpc_finish() to lose
-the traceback that caused the failure.  The transaction code was fixed
-to report the original error as well as any errors that occur while
-trying to recover from the original error.
-
-ZEO
----
-
-A ZEO client will not read from its cache during cache verification.
-This fix was necessary to prevent the client from reading inconsistent
-data.
-
-The isReadOnly() method of a ZEO client was fixed to return the false
-when the client is connected to a read-only fallback server.
-
-The sync() method of ClientStorage and the pending() method of a zrpc
-connection now do both input and output.
-
-The short_repr() function used to generate log messages was fixed so
-that it does not blow up creating a repr of very long tuples.
-
-Storages
---------
-
-FileStorage has a new pack() implementation that fixes several
-reported problems that could lead to data loss.
-
-Two small bugs were fixed in DemoStorage.  undoLog() did not handle
-its arguments correctly and pack() could accidentally delete objects
-created in versions.
-
-Fixed trivial bug in fsrecover that prevented it from working at all.
-
-FileStorage will use fsync() on Windows starting with Python 2.2.3.
-
-FileStorage's commit version was fixed.  It used to stop after the
-first object, leaving all the other objects in the version.
-
-BTrees
-------
-
-Trying to store an object of a non-integer type into an IIBTree
-or OIBTree could leave the bucket in a variety of insane states.  For
-example, trying
-
-    b[obj] = "I'm a string, not an integer"
-
-where b is an OIBTree.  This manifested as a refcount leak in the test
-suite, but could have been much worse (most likely in real life is that
-a seemingly arbitrary existing key would "go missing").
-
-When deleting the first child of a BTree node with more than one
-child, a reference to the second child leaked.  This could cause
-the entire bucket chain to leak (not be collected as garbage
-despite not being referenced anymore).
-
-Other minor BTree leak scenarios were also fixed.
-
-Other
------
-
-Comparing a Missing.Value object to a C type that provide its own
-comparison operation could lead to a segfault when the Missing.Value
-was on the right-hand side of the comparison operator.  The Missing
-class was fixed so that its coercion and comparison operations are
-safe.
-
-Tools
------
-
-Four tools are now installed by setup.py: fsdump.py, fstest.py,
-repozo.py, and zeopack.py.
-
-What's new in ZODB3 3.1.1 final?
-================================
-Release date: 11-Feb-2003
-
-Tools
------
-
-Updated repozo.py tool
-
-What's new in ZODB3 3.1.1 beta 2?
-=================================
-Release date: 03-Feb-2003
-
-The Transaction "hosed" feature is disabled in this release.  If a
-transaction fails during the tpc_finish() it is not possible, in
-general, to know whether the storage is in a consistent state.  For
-example, a ZEO server may commit the data and then fail before sending
-confirmation of the commit to the client.  If multiple storages are
-involved in a transaction, the problem is exacerbated: One storage may
-commit the data while another fails to commit.  In previous versions
-of ZODB, the database would set a global "hosed" flag that prevented
-any other transaction from committing until an administrator could
-check the status of the various failed storages and ensure that the
-database is in a consistent state.  This approach favors data
-consistency over availability.  The new approach is to log a panic but
-continue.  In practice, availability seems to be more important than
-consistency.  The failure mode is exceedingly rare in either case.
-
-The BTrees-based fsIndex for FileStorage is enabled.  This version of
-the index is faster to load and store via pickle and uses less memory
-to store keys.  We had intended to enable this feature in an earlier
-release, but failed to actually do it; thus, it's getting enabled as a
-bug fix now.
-
-Two rare bugs were fixed in BTrees conflict resolution.  The most
-probable symptom of the bug would have been a segfault.  The bugs
-were found via synthetic stress tests rather than bug reports.
-
-A value-based consistency checker for BTrees was added.  See the
-module BTrees.check for the checker and other utilities for working
-with BTrees.
-
-A new script called repozo.py was added.  This script, originally
-written by Anthony Baxter, provides an incremental backup scheme for
-FileStorage based storages.
-
-zeopack.py has been fixed to use a read-only connection.
-
-Various small autopack-related race conditions have been fixed in the
-Berkeley storage implementations.  There have been some table changes
-to the Berkeley storages so any storage you created in 3.1.1b1 may not
-work.  Part of these changes was to add a storage version number to
-the schema so these types of incompatible changes can be avoided in
-the future.
-
-Removed the chance of bogus warnings in the FileStorage iterator.
-
-ZEO
----
-
-The ZEO version number was bumped to 2.0.2 on account of the following
-minor feature additions.
-
-The performance of full cache verification has improved dramatically.
-Measurements from Jim were somewhere in 2x-5x.  The
-implementation was fixed to use the very-fast getSerial() method on
-the storage instead of the comparatively slow load().
-
-The ZEO server has an optional timeout feature that will abort a
-connection that does not commit within a certain amount of time.  The
-timeout works by closing the socket the client is using, causing both
-client and server to abort the transaction and continue.  This is a
-drastic step, but can be useful to prevent a hung client or other bug
-from blocking a server indefinitely.
-
-If a client was disconnected during a transaction, the tpc_abort()
-call did not properly reset the internal state about the transaction.
-The bug caused the next transaction to fail in its tpc_finish().
-Also, any ClientDisconnected exceptions raised during tpc_abort() are
-ignored.
-
-ZEO logging has been improved by adding more logging for important
-events, and changing the logging level for existing messages to a more
-appropriate level (usually lower).
-
-What's new in ZODB3 3.1.1 beta 1?
-=================================
-Release date: 10-Dev-2002
-
-It was possible for earlier versions of ZODB to deadlock when using
-multiple storages.  If multiple transactions committed concurrently
-and both transactions involved two or more shared storages, deadlock
-was possible.  This problem has been fixed by introducing a sortKey()
-method to the transaction and storage APIs that is used to define an
-ordering on transaction participants.  This solution will prevent
-deadlocks provided that all transaction participants that use locks
-define a valid sortKey() method.  A warning is raised if a participant
-does not define sortKey().  For backwards compatibility, BaseStorage
-provides a sortKey() that uses __name__.
-
-Added code to ThreadedAsync/LoopCallback.py to work around a bug in
-asyncore.py: a handled signal can cause unwanted reads to happen.
-
-A bug in FileStorage related to object uncreation was fixed.  If an
-a transaction that created an object was undone, FileStorage could
-write a bogus data record header that could lead to strange errors if
-the object was loaded.  An attempt to load an uncreated object now
-raises KeyError, as expected.
-
-The restore() implementation in FileStorage wrote incorrect
-backpointers for a few corner cases involving versions and undo.  It
-also failed if the backpointer pointed to a record that was before the
-pack time.  These specific bugs have been fixed and new test cases
-were added to cover them.
-
-A bug was fixed in conflict resolution that raised a NameError when a
-class involved in a conflict could not be loaded.  The bug did not
-affect correctness, but prevent ZODB from caching the fact that the
-class was unloadable.  A related bug prevented spurious
-AttributeErrors when a class could not be loaded.  It was also fixed.
-
-The script Tools/zeopack.py was fixed to work with ZEO 2.  It was
-untested and had two silly bugs.
-
-Some C extensions included standard header files before including
-Python.h, which is not allowed.  They now include Python.h first,
-which eliminates compiler warnings in certain configurations.
-
-The BerkeleyDB based storages have been merged from the trunk,
-providing a much more robust version of the storages.  They are not
-backwards compatible with the old storages, but the decision was made
-to update them in this micro release because the old storages did not
-work for all practical purposes.  For details, see Doc/BDBStorage.txt.
-
-What's new in ZODB3 3.1 final?
-===============================
-Release date: 28-Oct-2002
-
-If an error occurs during conflict resolution, the store will silently
-catch the error, log it, and continue as if the conflict was
-unresolvable.  ZODB used to behave this way, and the change to catch
-only ConflictError was causing problems in deployed systems.  There
-are a lot of legitimate errors that should be caught, but it's too
-close to the final release to make the substantial changes needed to
-correct this.
-
-What's new in ZODB3 3.1 beta 3?
-===============================
-Release date: 21-Oct-2002
-
-A small extension was made to the iterator protocol.  The Record
-objects, which are returned by the per-transaction iterators, contain
-a new `data_txn` attribute.  It is None, unless the data contained in
-the record is a logical copy of an earlier transaction's data.  For
-example, when transactional undo modifies an object, it creates a
-logical copy of the earlier transaction's data.  Note that this
-provide a stronger statement about consistency than whether the data
-in two records is the same; it's possible for two different updates to
-an object to coincidentally have the same data.
-
-The restore() method was extended to take the data_txn attribute
-mentioned above as an argument.  FileStorage uses the new argument to
-write a backpointer if possible.
-
-A few bugs were fixed.
-
-The setattr slot of the cPersistence C API was being initialized to
-NULL.  The proper initialization was restored, preventing crashes in
-some applications with C extensions that used persistence.
-
-The return value of TimeStamp's __cmp__ method was clipped to return
-only 1, 0, -1.
-
-The restore() method was fixed to write a valid backpointer if the
-update being restored is in a version.
-
-Several bugs and improvements were made to zdaemon, which can be used
-to run the ZEO server.  The parent now forwards signals to the child
-as intended.  Pidfile handling was improved and the trailing newline
-was omitted.
-
-What's new in ZODB3 3.1 beta 2?
-===============================
-Release date: 4-Oct-2002
-
-A few bugs have been fixed, some that were found with the help of
-Neal Norwitz's PyChecker.
-
-The zeoup.py tool has been fixed to allow connecting to a read-only
-storage, when the --nowrite option is given.
-
-Casey Duncan fixed a few bugs in the recent changes to undoLog().
-
-The fstest.py script no longer checks that each object modified in a
-transaction has a serial number that matches the transaction id.
-This invariant is no longer maintained; several new features in the
-3.1 release depend on it.
-
-The ZopeUndo package was added.  If ZODB3 is being used to run a ZEO
-server that will be used with Zope, it is usually best if the server
-and the Zope client don't share any software.  The Zope undo
-framework, however, requires that a Prefix object be passed between
-client and server.  To support this use, ZopeUndo was created to hold
-the Prefix object.
-
-Many bugs were fixed in ZEO, and a couple of features added.  See
-`ZEO-NEWS.txt` for details.
-
-The ZODB guide included in the Doc directory has been updated.  It is
-still incomplete, but most of the references to old ZODB packages have
-been removed.  There is a new section that briefly explains how to use
-BTrees.
-
-The zeoup.py tool connects using a read-only connection when --nowrite
-is specifified.  This feature is useful for checking on read-only ZEO
-servers.
-
-What's new in ZODB3 3.1 beta 1?
-===============================
-Release date: 12-Sep-2002
-
-We've changed the name and version number of the project, but it's
-still the same old ZODB.  There have been a lot of changes since the
-last release.
-
-New ZODB cache
---------------
-
-Toby Dickenson implemented a new Connection cache for ZODB.  The cache
-is responsible for pointer swizzling (translating between oids and
-Python objects) and for keeping recently used objects in memory.  The
-new cache is a big improvement over the old cache.  It strictly honors
-its size limit, where size is specified in number of objects, and it
-evicts objects in least recently used (LRU) order.
-
-Users should take care when setting the cache size, which has a
-default value of 400 objects.  The old version of the cache often held
-many more objects than its specified size.  An application may not
-perform as well with a small cache size, because the cache no longer
-exceeds the limit.
-
-Storages
---------
-
-The index used by FileStorage was reimplemented using a custom BTrees
-object.  The index maps oids to file offsets, and is kept in memory at
-all times.  The new index uses about 1/4 the memory of the old,
-dictionary-based index.  See the module ZODB.fsIndex for details.
-
-A security flaw was corrected in transactionalUndo().  The transaction
-ids returned by undoLog() and used for transactionalUndo() contained a
-file offset.  An attacker could construct a pickle with a bogus
-transaction record in its binary data, deduce the position of the
-pickle in the file from the undo log, then submit an undo with a bogus
-file position that caused the pickle to get written as a regular data
-record.  The implementation was fixed so that file offsets are not
-included in the transaction ids.
-
-Several storages now have an explicit read-only mode.  For example,
-passing the keyword argument read_only=1 to FileStorage will make it
-read-only.  If a write operation is performed on a read-only storage,
-a ReadOnlyError will be raised.
-
-The storage API was extended with new methods that support the Zope
-Replication Service (ZRS), a proprietary Zope Corp product.  We expect
-these methods to be generally useful.  The methods are:
-
-    - restore(oid, serialno, data, version, transaction)
-
-      Perform a store without doing consistency checks.  A client can
-      use this method to provide a new current revision of an object.
-      The ``serialno`` argument is the new serialno to use for the
-      object, not the serialno of the previous revision.
-
-    - lastTransaction()
-
-      Returns the transaction id of the last committed transaction.
-
-    - lastSerial(oid)
-
-      Return the current serialno for ``oid`` or None.
-
-    - iterator(start=None, stop=None)
-
-      The iterator method isn't new, but the optional ``start`` and
-      ``stop`` arguments are.  These arguments can be used to specify
-      the range of the iterator -- an inclusive range [start, stop].
-
-FileStorage is now more cautious about creating a new file when it
-believes a file does not exist.  This change is a workaround for bug
-in Python versions upto and including 2.1.3.  If the interpreter was
-builtin without large file support but the platform had it,
-os.path.exists() would return false for large files.  The fix is to
-try to open the file first, and decide whether to create a new file
-based on errno.
-
-The undoLog() and undoInfo() methods of FileStorage can run
-concurrently with other methods.  The internal storage lock is
-released periodically to give other threads a chance to run.  This
-should increase responsiveness of ZEO clients when used with ZEO 2.
-
-New serial numbers are assigned consistently for abortVersion() and
-commitVersion().  When a version is committed, the non-version data
-gets a new serial number.  When a version is aborted, the serial
-number for non-version data does not change.  This means that the
-abortVersion() transaction record has the unique property that its
-transaction id is not the serial number of the data records.
-
-
-Berkeley Storages
------------------
-
-Berkeley storage constructors now take an optional `config` argument,
-which is an instance whose attributes can be used to configure such
-BerkeleyDB policies as an automatic checkpointing interval, lock table
-sizing, and the log directory.  See bsddb3Storage/BerkeleyBase.py for
-details.
-
-A getSize() method has been added to all Berkeley storages.
-
-Berkeley storages open their environments with the DB_THREAD flag.
-
-Some performance optimizations have been implemented in Full storage,
-including the addition of a helper C extension when used with Python
-2.2.  More performance improvements will be added for the ZODB 3.1
-final release.
-
-A new experimental Autopack storage was added which keeps only a
-certain amount of old revision information.  The concepts in this
-storage will be folded into Full and Autopack will likely go away in
-ZODB 3.1 final.  ZODB 3.1 final will also have much improved Minimal
-and Full storages, which eliminate Berkeley lock exhaustion problems,
-reduce memory use, and improve performance.
-
-It is recommended that you use BerkeleyDB 4.0.14 and PyBSDDB 3.4.0
-with the Berkeley storages.  See bsddb3Storage/README.txt for details.
-
-
-BTrees
-------
-
-BTrees no longer ignore exceptions raised when two keys are compared.
-
-Tim Peters fixed several endcase bugs in the BTrees code.  Most
-importantly, after a mix of inserts and deletes in a BTree or TreeSet, it
-was possible (but unlikely) for the internal state of the object to become
-inconsistent.  Symptoms then varied; most often this manifested as a
-mysterious failure to find a key that you knew was present, or that
-tree.keys() would yield an object that disgreed with the tree about
-how many keys there were.
-
-If you suspect such a problem, BTrees and TreeSets now support a ._check()
-method, which does a thorough job of examining the internal tree pointers
-for consistency.  It raises AssertionError if it finds any problems, else
-returns None.  If ._check() raises an exception, the object is damaged,
-and rebuilding the object is the best solution.  All known ways for a
-BTree or TreeSet object to become internally inconsistent have been
-repaired.
-
-Other fixes include:
-
-- Many fixes for range search endcases, including the "range search bug:"
-  If the smallest key S in a bucket in a BTree was deleted, doing a range
-  search on the BTree with S on the high end could claim that the range
-  was empty even when it wasn't.
-
-- Zope Collector #419:  repaired off-by-1 errors and IndexErrors when
-  slicing BTree-based data structures.  For example,
-  an_IIBTree.items()[0:0] had length 1 (should be empty) if the tree
-  wasn't empty.
-
-- The BTree module functions weightedIntersection() and weightedUnion()
-  now treat negative weights as documented.  It's hard to explain what
-  their effects were before this fix, as the sign bits were getting
-  confused with an internal distinction between whether the result
-  should be a set or a mapping.
-
-ZEO
-----
-
-For news about ZEO2, see the file ZEO-NEWS.txt.
-
-This version of ZODB ships with two different versions of ZEO.  It
-includes ZEO 2.0 beta 1, the recommended new version.  (ZEO 2 will
-reach final release before ZODB3.)  The ZEO 2.0 protocol is not
-compatible with ZEO 1.0, so we have also included ZEO 1.0 to support
-people already using ZEO 1.0.
-
-Other features
---------------
-
-When a ConflictError is raised, the exception object now has a
-sensible structure, thanks to a patch from Greg Ward.  The exception
-now uses the following standard attributes: oid, class_name, message,
-serials.  See the ZODB.POSException.ConflictError doc string for
-details.
-
-It is now easier to customize the registration of persistent objects
-with a transaction.  The low-level persistence mechanism in
-cPersistence.c registers with the object's jar instead of with the
-current transaction.  The jar (Connection) then registers with the
-transaction.  This redirection would allow specialized Connections to
-change the default policy on how the transaction manager is selected
-without hacking the Transaction module.
-
-Empty transactions can be committed without interacting with the
-storage.  It is possible for registration to occur unintentionally and
-for a persistent object to compensate by making itself as unchanged.
-When this happens, it's possible to commit a transaction with no
-modified objects.  The change allows such transactions to finish even
-on a read-only storage.
-
-Two new tools were added to the Tools directory.  The ``analyze.py``
-script, based on a tool by Matt Kromer, prints a summary of space
-usage in a FileStorage Data.fs.  The ``checkbtrees.py`` script scans a
-FileStorage Data.fs.  When it finds a BTrees object, it loads the
-object and calls the ``_check`` method.  It prints warning messages
-for any corrupt BTrees objects found.
-
-Documentation
--------------
-
-The user's guide included with this release is still woefully out of date.
-
-Other bugs fixed
-----------------
-
-If an exception occurs inside an _p_deactivate() method, a traceback
-is printed on stderr.  Previous versions of ZODB silently cleared the
-exception.
-
-ExtensionClass and ZODB now work correctly with a Python debug build.
-
-All C code has been fixed to use a consistent set of functions from
-the Python memory API.  This allows ZODB to be used in conjunction
-with pymalloc, the default allocator in Python 2.3.
-
-zdaemon, which can be used to run a ZEO server, more clearly reports
-the exit status of its child processes.
-
-The ZEO server will reinitialize zLOG when it receives a SIGHUP.  This
-allows log file rotation without restarting the server.
-
-What's new in StandaloneZODB 1.0 final?
-=======================================
-Release date: 08-Feb-2002
-
-All copyright notices have been updated to reflect the fact that the
-ZPL 2.0 covers this release.
-
-Added a cleanroom PersistentList.py implementation, which multiply
-inherits from UserDict and Persistent.
-
-Some improvements in setup.py and test.py for sites that don't have
-the Berkeley libraries installed.
-
-A new program, zeoup.py was added which simply verifies that a ZEO
-server is reachable.  Also, a new program zeopack.py was added which
-connects to a ZEO server and packs it.
-
-
-What's new in StandaloneZODB 1.0 c1?
-====================================
-Release Date: 25-Jan-2002
-
-This was the first public release of the StandaloneZODB from Zope
-Corporation.   Everything's new! :)

Deleted: ZODB/trunk/LICENSE.txt
===================================================================
--- ZODB/trunk/LICENSE.txt	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/LICENSE.txt	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,44 +0,0 @@
-Zope Public License (ZPL) Version 2.1
-
-A copyright notice accompanies this license document that identifies the
-copyright holders.
-
-This license has been certified as open source. It has also been designated as
-GPL compatible by the Free Software Foundation (FSF).
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions are met:
-
-1. Redistributions in source code must retain the accompanying copyright
-notice, this list of conditions, and the following disclaimer.
-
-2. Redistributions in binary form must reproduce the accompanying copyright
-notice, this list of conditions, and the following disclaimer in the
-documentation and/or other materials provided with the distribution.
-
-3. Names of the copyright holders must not be used to endorse or promote
-products derived from this software without prior written permission from the
-copyright holders.
-
-4. The right to distribute this software or to use it for any purpose does not
-give you the right to use Servicemarks (sm) or Trademarks (tm) of the
-copyright
-holders. Use of them is covered by separate agreement with the copyright
-holders.
-
-5. If any files are modified, you must cause the modified files to carry
-prominent notices stating that you changed the files and the date of any
-change.
-
-Disclaimer
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS'' AND ANY EXPRESSED
-OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
-OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
-EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY DIRECT, INDIRECT,
-INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
-PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
-LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
-NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
-EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Added: ZODB/trunk/MOVED_TO_GITHUB
===================================================================
--- ZODB/trunk/MOVED_TO_GITHUB	                        (rev 0)
+++ ZODB/trunk/MOVED_TO_GITHUB	2013-01-05 18:57:01 UTC (rev 129018)
@@ -0,0 +1 @@
+See https://github.com/zopefoundation/ZODB


Property changes on: ZODB/trunk/MOVED_TO_GITHUB
___________________________________________________________________
Added: svn:eol-style
   + native

Deleted: ZODB/trunk/README.txt
===================================================================
--- ZODB/trunk/README.txt	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/README.txt	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,140 +0,0 @@
-====
-ZODB
-====
-
-Introduction
-============
-
-The ZODB  package provides a  set of tools  for using the  Zope Object
-Database (ZODB).
-
-Our primary development platforms are Linux and Mac OS X.  The test
-suite should pass without error on these platforms and, hopefully,
-Windows, although it can take a long time on Windows -- longer if you
-use ZoneAlarm.
-
-Compatibility
-=============
-
-ZODB 4.0 requires Python 2.6 or 2.7.
-
-Prerequisites
-=============
-
-You must have Python installed. If you're using a system Python
-install, make sure development support is installed too.
-
-You also need the transaction, BTrees, persistent, zc.lockfile,
-ZConfig, zdaemon, zope.event, zope.interface, zope.proxy and
-zope.testing packages.  If you don't have them and you can connect to
-the Python Package Index, then these will be installed for you if you
-don't have them.
-
-Installation
-============
-
-ZODB is released as a distutils package.  The easiest ways to build
-and install it are to use `easy_install
-<http://peak.telecommunity.com/DevCenter/EasyInstall>`_, or
-`zc.buildout <http://www.python.org/pypi/zc.buildout>`_.
-
-To install by hand, first install the dependencies, ZConfig, zdaemon,
-zope.interface, zope.proxy and zope.testing.  These can be found
-in the `Python Package Index <http://www.python.org/pypi>`_.
-
-To run the tests, use the test setup command::
-
-  python setup.py test
-
-It will download dependencies if needed.  If this happens, ou may get
-an import error when the test command gets to looking for tests.  Try
-running the test command a second time and you should see the tests
-run.
-
-::
-
-  python setup.py test
-
-To install, use the install command::
-
-  python setup.py install
-
-
-Testing for Developers
-======================
-
-The ZODB checkouts are `buildouts <http://www.python.org/pypi/zc.buildout>`_.
-When working from a ZODB checkout, first run the bootstrap.py script
-to initialize the buildout:
-
-    % python bootstrap.py
-
-and then use the buildout script to build ZODB and gather the dependencies:
-
-    % bin/buildout
-
-This creates a test script:
-
-    % bin/test -v
-
-This command will run all the tests, printing a single dot for each
-test.  When it finishes, it will print a test summary.  The exact
-number of tests can vary depending on platform and available
-third-party libraries.::
-
-    Ran 1182 tests in 241.269s
-
-    OK
-
-The test script has many more options.  Use the ``-h`` or ``--help``
-options to see a file list of options.  The default test suite omits
-several tests that depend on third-party software or that take a long
-time to run.  To run all the available tests use the ``--all`` option.
-Running all the tests takes much longer.::
-
-    Ran 1561 tests in 1461.557s
-
-    OK
-
-
-Maintenance scripts
--------------------
-
-Several scripts are provided with the ZODB and can help for analyzing,
-debugging, checking for consistency, summarizing content, reporting space used
-by objects, doing backups, artificial load testing, etc.
-Look at the ZODB/script directory for more informations.
-
-License
-=======
-
-ZODB is distributed under the Zope Public License, an OSI-approved
-open source license.  Please see the LICENSE.txt file for terms and
-conditions.
-
-More information
-================
-
-See http://zodb.org/
-
-There is a Mailman mailing list in place to discuss all issues related
-to ZODB.  You can send questions to
-
-    zodb-dev at zope.org
-
-or subscribe at
-
-    http://lists.zope.org/mailman/listinfo/zodb-dev
-
-and view its archives at
-
-    http://lists.zope.org/pipermail/zodb-dev
-
-Note that Zope Corp mailing lists have a subscriber-only posting policy.
-
-Bugs and Patches
-================
-
-Bug reports and patches should be added to the Launchpad:
-
-    https://launchpad.net/zodb

Deleted: ZODB/trunk/bootstrap.py
===================================================================
--- ZODB/trunk/bootstrap.py	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/bootstrap.py	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,66 +0,0 @@
-##############################################################################
-#
-# Copyright (c) 2006 Zope Foundation and Contributors.
-# All Rights Reserved.
-#
-# This software is subject to the provisions of the Zope Public License,
-# Version 2.1 (ZPL).  A copy of the ZPL should accompany this distribution.
-# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
-# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
-# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
-# FOR A PARTICULAR PURPOSE.
-#
-##############################################################################
-"""Bootstrap a buildout-based project
-
-Simply run this script in a directory containing a buildout.cfg.
-The script accepts buildout command-line options, so you can
-use the -c option to specify an alternate configuration file.
-"""
-
-import os, shutil, sys, tempfile, urllib2
-
-tmpeggs = tempfile.mkdtemp()
-
-ez = {}
-exec urllib2.urlopen('http://peak.telecommunity.com/dist/ez_setup.py'
-                     ).read() in ez
-ez['use_setuptools'](to_dir=tmpeggs, download_delay=0)
-
-import pkg_resources
-
-is_jython = sys.platform.startswith('java')
-
-if is_jython:
-    import subprocess
-
-cmd = 'from setuptools.command.easy_install import main; main()'
-if sys.platform == 'win32':
-    cmd = '"%s"' % cmd # work around spawn lamosity on windows
-
-ws = pkg_resources.working_set
-
-if is_jython:
-    assert subprocess.Popen(
-    [sys.executable] + ['-c', cmd, '-mqNxd', tmpeggs, 'zc.buildout'],
-    env = dict(os.environ,
-          PYTHONPATH=
-          ws.find(pkg_resources.Requirement.parse('setuptools')).location
-          ),
-    ).wait() == 0
-
-else:
-    assert os.spawnle(
-        os.P_WAIT, sys.executable, sys.executable,
-        '-c', cmd, '-mqNxd', tmpeggs, 'zc.buildout',
-        dict(os.environ,
-            PYTHONPATH=
-            ws.find(pkg_resources.Requirement.parse('setuptools')).location
-            ),
-        ) == 0
-
-ws.add_entry(tmpeggs)
-ws.require('zc.buildout')
-import zc.buildout.buildout
-zc.buildout.buildout.main(sys.argv[1:] + ['bootstrap'])
-shutil.rmtree(tmpeggs)

Deleted: ZODB/trunk/buildout.cfg
===================================================================
--- ZODB/trunk/buildout.cfg	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/buildout.cfg	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,27 +0,0 @@
-[buildout]
-develop = .
-parts =
-    test
-    scripts
-versions = versions
-
-[versions]
-zc.recipe.testrunner = 1.3.0
-
-[test]
-recipe = zc.recipe.testrunner
-eggs =
-    persistent
-    BTrees
-    ZODB [test]
-initialization =
-  import os, tempfile
-  try: os.mkdir('tmp')
-  except: pass
-  tempfile.tempdir = os.path.abspath('tmp')
-defaults = ['--all']
-
-[scripts]
-recipe = zc.recipe.egg
-eggs = ${test:eggs}
-interpreter = py

Deleted: ZODB/trunk/ez_setup.py
===================================================================
--- ZODB/trunk/ez_setup.py	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/ez_setup.py	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,276 +0,0 @@
-#!python
-"""Bootstrap setuptools installation
-
-If you want to use setuptools in your package's setup.py, just include this
-file in the same directory with it, and add this to the top of your setup.py::
-
-    from ez_setup import use_setuptools
-    use_setuptools()
-
-If you want to require a specific version of setuptools, set a download
-mirror, or use an alternate download directory, you can do so by supplying
-the appropriate options to ``use_setuptools()``.
-
-This file can also be run as a script to install or upgrade setuptools.
-"""
-import sys
-DEFAULT_VERSION = "0.6c9"
-DEFAULT_URL     = "http://pypi.python.org/packages/%s/s/setuptools/" % sys.version[:3]
-
-md5_data = {
-    'setuptools-0.6b1-py2.3.egg': '8822caf901250d848b996b7f25c6e6ca',
-    'setuptools-0.6b1-py2.4.egg': 'b79a8a403e4502fbb85ee3f1941735cb',
-    'setuptools-0.6b2-py2.3.egg': '5657759d8a6d8fc44070a9d07272d99b',
-    'setuptools-0.6b2-py2.4.egg': '4996a8d169d2be661fa32a6e52e4f82a',
-    'setuptools-0.6b3-py2.3.egg': 'bb31c0fc7399a63579975cad9f5a0618',
-    'setuptools-0.6b3-py2.4.egg': '38a8c6b3d6ecd22247f179f7da669fac',
-    'setuptools-0.6b4-py2.3.egg': '62045a24ed4e1ebc77fe039aa4e6f7e5',
-    'setuptools-0.6b4-py2.4.egg': '4cb2a185d228dacffb2d17f103b3b1c4',
-    'setuptools-0.6c1-py2.3.egg': 'b3f2b5539d65cb7f74ad79127f1a908c',
-    'setuptools-0.6c1-py2.4.egg': 'b45adeda0667d2d2ffe14009364f2a4b',
-    'setuptools-0.6c2-py2.3.egg': 'f0064bf6aa2b7d0f3ba0b43f20817c27',
-    'setuptools-0.6c2-py2.4.egg': '616192eec35f47e8ea16cd6a122b7277',
-    'setuptools-0.6c3-py2.3.egg': 'f181fa125dfe85a259c9cd6f1d7b78fa',
-    'setuptools-0.6c3-py2.4.egg': 'e0ed74682c998bfb73bf803a50e7b71e',
-    'setuptools-0.6c3-py2.5.egg': 'abef16fdd61955514841c7c6bd98965e',
-    'setuptools-0.6c4-py2.3.egg': 'b0b9131acab32022bfac7f44c5d7971f',
-    'setuptools-0.6c4-py2.4.egg': '2a1f9656d4fbf3c97bf946c0a124e6e2',
-    'setuptools-0.6c4-py2.5.egg': '8f5a052e32cdb9c72bcf4b5526f28afc',
-    'setuptools-0.6c5-py2.3.egg': 'ee9fd80965da04f2f3e6b3576e9d8167',
-    'setuptools-0.6c5-py2.4.egg': 'afe2adf1c01701ee841761f5bcd8aa64',
-    'setuptools-0.6c5-py2.5.egg': 'a8d3f61494ccaa8714dfed37bccd3d5d',
-    'setuptools-0.6c6-py2.3.egg': '35686b78116a668847237b69d549ec20',
-    'setuptools-0.6c6-py2.4.egg': '3c56af57be3225019260a644430065ab',
-    'setuptools-0.6c6-py2.5.egg': 'b2f8a7520709a5b34f80946de5f02f53',
-    'setuptools-0.6c7-py2.3.egg': '209fdf9adc3a615e5115b725658e13e2',
-    'setuptools-0.6c7-py2.4.egg': '5a8f954807d46a0fb67cf1f26c55a82e',
-    'setuptools-0.6c7-py2.5.egg': '45d2ad28f9750e7434111fde831e8372',
-    'setuptools-0.6c8-py2.3.egg': '50759d29b349db8cfd807ba8303f1902',
-    'setuptools-0.6c8-py2.4.egg': 'cba38d74f7d483c06e9daa6070cce6de',
-    'setuptools-0.6c8-py2.5.egg': '1721747ee329dc150590a58b3e1ac95b',
-    'setuptools-0.6c9-py2.3.egg': 'a83c4020414807b496e4cfbe08507c03',
-    'setuptools-0.6c9-py2.4.egg': '260a2be2e5388d66bdaee06abec6342a',
-    'setuptools-0.6c9-py2.5.egg': 'fe67c3e5a17b12c0e7c541b7ea43a8e6',
-    'setuptools-0.6c9-py2.6.egg': 'ca37b1ff16fa2ede6e19383e7b59245a',
-}
-
-import sys, os
-try: from hashlib import md5
-except ImportError: from md5 import md5
-
-def _validate_md5(egg_name, data):
-    if egg_name in md5_data:
-        digest = md5(data).hexdigest()
-        if digest != md5_data[egg_name]:
-            print >>sys.stderr, (
-                "md5 validation of %s failed!  (Possible download problem?)"
-                % egg_name
-            )
-            sys.exit(2)
-    return data
-
-def use_setuptools(
-    version=DEFAULT_VERSION, download_base=DEFAULT_URL, to_dir=os.curdir,
-    download_delay=15
-):
-    """Automatically find/download setuptools and make it available on sys.path
-
-    `version` should be a valid setuptools version number that is available
-    as an egg for download under the `download_base` URL (which should end with
-    a '/').  `to_dir` is the directory where setuptools will be downloaded, if
-    it is not already available.  If `download_delay` is specified, it should
-    be the number of seconds that will be paused before initiating a download,
-    should one be required.  If an older version of setuptools is installed,
-    this routine will print a message to ``sys.stderr`` and raise SystemExit in
-    an attempt to abort the calling script.
-    """
-    was_imported = 'pkg_resources' in sys.modules or 'setuptools' in sys.modules
-    def do_download():
-        egg = download_setuptools(version, download_base, to_dir, download_delay)
-        sys.path.insert(0, egg)
-        import setuptools; setuptools.bootstrap_install_from = egg
-    try:
-        import pkg_resources
-    except ImportError:
-        return do_download()       
-    try:
-        pkg_resources.require("setuptools>="+version); return
-    except pkg_resources.VersionConflict, e:
-        if was_imported:
-            print >>sys.stderr, (
-            "The required version of setuptools (>=%s) is not available, and\n"
-            "can't be installed while this script is running. Please install\n"
-            " a more recent version first, using 'easy_install -U setuptools'."
-            "\n\n(Currently using %r)"
-            ) % (version, e.args[0])
-            sys.exit(2)
-        else:
-            del pkg_resources, sys.modules['pkg_resources']    # reload ok
-            return do_download()
-    except pkg_resources.DistributionNotFound:
-        return do_download()
-
-def download_setuptools(
-    version=DEFAULT_VERSION, download_base=DEFAULT_URL, to_dir=os.curdir,
-    delay = 15
-):
-    """Download setuptools from a specified location and return its filename
-
-    `version` should be a valid setuptools version number that is available
-    as an egg for download under the `download_base` URL (which should end
-    with a '/'). `to_dir` is the directory where the egg will be downloaded.
-    `delay` is the number of seconds to pause before an actual download attempt.
-    """
-    import urllib2, shutil
-    egg_name = "setuptools-%s-py%s.egg" % (version,sys.version[:3])
-    url = download_base + egg_name
-    saveto = os.path.join(to_dir, egg_name)
-    src = dst = None
-    if not os.path.exists(saveto):  # Avoid repeated downloads
-        try:
-            from distutils import log
-            if delay:
-                log.warn("""
----------------------------------------------------------------------------
-This script requires setuptools version %s to run (even to display
-help).  I will attempt to download it for you (from
-%s), but
-you may need to enable firewall access for this script first.
-I will start the download in %d seconds.
-
-(Note: if this machine does not have network access, please obtain the file
-
-   %s
-
-and place it in this directory before rerunning this script.)
----------------------------------------------------------------------------""",
-                    version, download_base, delay, url
-                ); from time import sleep; sleep(delay)
-            log.warn("Downloading %s", url)
-            src = urllib2.urlopen(url)
-            # Read/write all in one block, so we don't create a corrupt file
-            # if the download is interrupted.
-            data = _validate_md5(egg_name, src.read())
-            dst = open(saveto,"wb"); dst.write(data)
-        finally:
-            if src: src.close()
-            if dst: dst.close()
-    return os.path.realpath(saveto)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-def main(argv, version=DEFAULT_VERSION):
-    """Install or upgrade setuptools and EasyInstall"""
-    try:
-        import setuptools
-    except ImportError:
-        egg = None
-        try:
-            egg = download_setuptools(version, delay=0)
-            sys.path.insert(0,egg)
-            from setuptools.command.easy_install import main
-            return main(list(argv)+[egg])   # we're done here
-        finally:
-            if egg and os.path.exists(egg):
-                os.unlink(egg)
-    else:
-        if setuptools.__version__ == '0.0.1':
-            print >>sys.stderr, (
-            "You have an obsolete version of setuptools installed.  Please\n"
-            "remove it from your system entirely before rerunning this script."
-            )
-            sys.exit(2)
-
-    req = "setuptools>="+version
-    import pkg_resources
-    try:
-        pkg_resources.require(req)
-    except pkg_resources.VersionConflict:
-        try:
-            from setuptools.command.easy_install import main
-        except ImportError:
-            from easy_install import main
-        main(list(argv)+[download_setuptools(delay=0)])
-        sys.exit(0) # try to force an exit
-    else:
-        if argv:
-            from setuptools.command.easy_install import main
-            main(argv)
-        else:
-            print "Setuptools version",version,"or greater has been installed."
-            print '(Run "ez_setup.py -U setuptools" to reinstall or upgrade.)'
-
-def update_md5(filenames):
-    """Update our built-in md5 registry"""
-
-    import re
-
-    for name in filenames:
-        base = os.path.basename(name)
-        f = open(name,'rb')
-        md5_data[base] = md5(f.read()).hexdigest()
-        f.close()
-
-    data = ["    %r: %r,\n" % it for it in md5_data.items()]
-    data.sort()
-    repl = "".join(data)
-
-    import inspect
-    srcfile = inspect.getsourcefile(sys.modules[__name__])
-    f = open(srcfile, 'rb'); src = f.read(); f.close()
-
-    match = re.search("\nmd5_data = {\n([^}]+)}", src)
-    if not match:
-        print >>sys.stderr, "Internal error!"
-        sys.exit(2)
-
-    src = src[:match.start(1)] + repl + src[match.end(1):]
-    f = open(srcfile,'w')
-    f.write(src)
-    f.close()
-
-
-if __name__=='__main__':
-    if len(sys.argv)>2 and sys.argv[1]=='--md5update':
-        update_md5(sys.argv[2:])
-    else:
-        main(sys.argv[1:])
-
-
-
-
-
-

Deleted: ZODB/trunk/log.ini
===================================================================
--- ZODB/trunk/log.ini	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/log.ini	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,32 +0,0 @@
-# This file configures the logging module for the test harness:
-# critical errors are logged to testing.log; everything else is
-# ignored.
-
-# Documentation for the file format is at
-# http://www.red-dove.com/python_logging.html#config
-
-[logger_root]
-level=CRITICAL
-handlers=normal
-
-[handler_normal]
-class=FileHandler
-level=NOTSET
-formatter=common
-args=('testing.log', 'a')
-filename=testing.log
-mode=a
-
-[formatter_common]
-format=------
-       %(asctime)s %(levelname)s %(name)s %(message)s
-datefmt=%Y-%m-%dT%H:%M:%S
-
-[loggers]
-keys=root
-
-[handlers]
-keys=normal
-
-[formatters]
-keys=common

Deleted: ZODB/trunk/release.py
===================================================================
--- ZODB/trunk/release.py	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/release.py	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,81 +0,0 @@
-#! /usr/bin/env python
-"""Update version numbers and release dates for the next release.
-
-usage: release.py version date
-
-version should be a string like "3.2.0c1"
-date should be a string like "23-Sep-2003"
-
-The following files are updated:
-    - setup.py
-    - NEWS.txt
-    - doc/guide/zodb.tex
-    - src/ZEO/__init__.py
-    - src/ZEO/version.txt
-    - src/ZODB/__init__.py
-"""
-
-import fileinput
-import os
-import re
-
-# In file filename, replace the first occurrence of regexp pat with
-# string repl.
-def replace(filename, pat, repl):
-    from sys import stderr as e # fileinput hijacks sys.stdout
-    foundone = False
-    for line in fileinput.input([filename], inplace=True, backup="~"):
-        if foundone:
-            print line,
-        else:
-            match = re.search(pat, line)
-            if match is not None:
-                foundone = True
-
-                new = re.sub(pat, repl, line)
-                print new,
-
-                print >> e, "In %s, replaced:" % filename
-                print >> e, "   ", repr(line)
-                print >> e, "   ", repr(new)
-
-            else:
-                print line,
-
-    if not foundone:
-        print >> e, "*" * 60, "Oops!"
-        print >> e, "    Failed to find %r in %r" % (pat, filename)
-
-# Nothing in our codebase cares about ZEO/version.txt.  Jeremy said
-# someone asked for it so that a shell script could read up the ZEO
-# version easily.
-# Before ZODB 3.4, the ZEO version was one smaller than the ZODB version;
-# e.g., ZEO 2.2.7 shipped with ZODB 3.2.7.  Now ZEO and ZODB share their
-# version number.
-def write_zeoversion(path, version):
-    f = open(path, "w")
-    print >> f, version
-    f.close()
-
-def main(args):
-    version, date = args
-
-    replace("setup.py",
-            r'^VERSION = "\S+"$',
-            'VERSION = "%s"' % version)
-    replace("src/ZODB/__init__.py",
-            r'__version__ = "\S+"',
-            '__version__ = "%s"' % version)
-    replace("src/ZEO/__init__.py",
-            r'version = "\S+"',
-            'version = "%s"' % version)
-    write_zeoversion("src/ZEO/version.txt", version)
-    replace("NEWS.txt",
-            r"^Release date: .*",
-            "Release date: %s" % date)
-    replace("doc/guide/zodb.tex",
-            r"release{\S+}",
-            "release{%s}" % version)
-if __name__ == "__main__":
-    import sys
-    main(sys.argv[1:])

Deleted: ZODB/trunk/setup.py
===================================================================
--- ZODB/trunk/setup.py	2013-01-04 20:04:12 UTC (rev 129017)
+++ ZODB/trunk/setup.py	2013-01-05 18:57:01 UTC (rev 129018)
@@ -1,145 +0,0 @@
-##############################################################################
-#
-# Copyright (c) 2002, 2003 Zope Foundation and Contributors.
-# All Rights Reserved.
-#
-# This software is subject to the provisions of the Zope Public License,
-# Version 2.1 (ZPL).  A copy of the ZPL should accompany this distribution.
-# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
-# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
-# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
-# FOR A PARTICULAR PURPOSE.
-#
-##############################################################################
-"""Zope Object Database: object database and persistence
-
-The Zope Object Database provides an object-oriented database for
-Python that provides a high-degree of transparency. Applications can
-take advantage of object database features with few, if any, changes
-to application logic.  ZODB includes features such as a plugable storage
-interface, rich transaction support, and undo.
-"""
-
-VERSION = "4.0.0dev"
-
-from ez_setup import use_setuptools
-use_setuptools()
-
-from setuptools import setup, find_packages
-from setuptools.extension import Extension
-import os
-import sys
-
-if sys.version_info < (2, 6):
-    print "This version of ZODB requires Python 2.6 or higher"
-    sys.exit(0)
-
-# The (non-obvious!) choices for the Trove Development Status line:
-# Development Status :: 5 - Production/Stable
-# Development Status :: 4 - Beta
-# Development Status :: 3 - Alpha
-
-classifiers = """\
-Intended Audience :: Developers
-License :: OSI Approved :: Zope Public License
-Programming Language :: Python
-Programming Language :: Python :: 2.6
-Programming Language :: Python :: 2.7
-Topic :: Database
-Topic :: Software Development :: Libraries :: Python Modules
-Operating System :: Microsoft :: Windows
-Operating System :: Unix
-Framework :: ZODB
-"""
-
-def _modname(path, base, name=''):
-    if path == base:
-        return name
-    dirname, basename = os.path.split(path)
-    return _modname(dirname, base, basename + '.' + name)
-
-def alltests():
-    import logging
-    import pkg_resources
-    import unittest
-
-    # Something wacked in setting recursion limit when running setup test
-    import ZODB.FileStorage.tests
-    del ZODB.FileStorage.tests._save_index
-
-    class NullHandler(logging.Handler):
-        level = 50
-
-        def emit(self, record):
-            pass
-
-    logging.getLogger().addHandler(NullHandler())
-
-    suite = unittest.TestSuite()
-    base = pkg_resources.working_set.find(
-        pkg_resources.Requirement.parse('ZODB')).location
-    for dirpath, dirnames, filenames in os.walk(base):
-        if os.path.basename(dirpath) == 'tests':
-            for filename in filenames:
-                if filename.endswith('.py') and filename.startswith('test'):
-                    mod = __import__(
-                        _modname(dirpath, base, os.path.splitext(filename)[0]),
-                        {}, {}, ['*'])
-                    suite.addTest(mod.test_suite())
-        elif 'tests.py' in filenames:
-            mod = __import__(_modname(dirpath, base, 'tests'), {}, {}, ['*'])
-            suite.addTest(mod.test_suite())
-    return suite
-
-doclines = __doc__.split("\n")
-
-def read_file(*path):
-    base_dir = os.path.dirname(__file__)
-    file_path = (base_dir, ) + tuple(path)
-    return file(os.path.join(*file_path)).read()
-
-long_description = str(
-    ("\n".join(doclines[2:]) + "\n\n" +
-     ".. contents::\n\n" +
-     read_file("README.txt")  + "\n\n" +
-     read_file("CHANGES.txt")
-    ).decode('latin-1').replace(u'L\xf6wis', '|Lowis|')
-    )+ '''\n\n.. |Lowis| unicode:: L \\xf6 wis\n'''
-
-tests_require = ['zope.testing', 'manuel']
-
-setup(name="ZODB",
-      version=VERSION,
-      setup_requires=['persistent'],
-      maintainer="Zope Foundation and Contributors",
-      maintainer_email="zodb-dev at zope.org",
-      packages = find_packages('src'),
-      package_dir = {'': 'src'},
-      license = "ZPL 2.1",
-      platforms = ["any"],
-      description = doclines[0],
-      classifiers = filter(None, classifiers.split("\n")),
-      long_description = long_description,
-      test_suite="__main__.alltests", # to support "setup.py test"
-      tests_require = tests_require,
-      extras_require = dict(test=tests_require),
-      install_requires = [
-        'transaction',
-        'persistent',
-        'BTrees',
-        'zc.lockfile',
-        'ZConfig',
-        'zdaemon',
-        'zope.interface',
-        ],
-      zip_safe = False,
-      entry_points = """
-      [console_scripts]
-      fsdump = ZODB.FileStorage.fsdump:main
-      fsoids = ZODB.scripts.fsoids:main
-      fsrefs = ZODB.scripts.fsrefs:main
-      fstail = ZODB.scripts.fstail:Main
-      repozo = ZODB.scripts.repozo:main
-      """,
-      include_package_data = True,
-      )



More information about the Zodb-checkins mailing list