unnecessarily blocked other activity.

  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.

usually passed. :(

causing extra pain on windows.

accross revs.

after conflict errors on blobs. :(

servers much easier. This was easier than I expected. I should have
done this a long time ago. :)

----------

- The helper function ZODB.blob.is_blob_record didn't handle having
  None passed to it, but database "delete" records have None for their
  data.

- 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.

Fixed to use a separate Random instance.

----------

- 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.)

setuptools installed.

https://bugs.launchpad.net/zodb/+bug/185066

The fix didn't go far enough and a fix that would go far enough would
be too risky this late in the 3.9 beta cycle.  This will probably need
to wait till 3.10.

  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

  Savepoint blob data wasn't cleaned up after a transaction abort.
  https://bugs.launchpad.net/zodb/+bug/323067