- A ZEO threading bug could cause transactions to read inconsistent
  data.  (This sometimes caused an AssertionError in
  Connection._setstate_noncurrent.)

after conflict errors on blobs. :(

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

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

  Objects defining _p_deactivate methods that didn't call base methods
  weren't loaded properly. https://bugs.launchpad.net/zodb/+bug/185066

  Calling __setstate__ on a persistent object could under certain
  uncommon cause the process to crash.

- There's a new utility script, strip_versions that strips version
  data from storages. This is needed to prepare databases containing
  version records for using ZODB 3.9, which no-longer supports
  versions.

- 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

- Limit the number of object ids that can be allocated at once to
  avoid running out of memory.

merge a couple of years ago.  Fortunately, they still pass, so no new
release is indicated.

I didn't restore and removed one silly test class, OneTimeTests,
related to obsolete packing issues.

I didn't restore and removed another silly test class,
DemoStorageWrappedAroundClientStorage, because it is an error to wrap
a demo storage around a client storage. A DemoStorage should only wrap
a storage who's data never changes.

return an object count of 0.

- This change prevent reads from the old cache object, e.g. during Zope2's
  auto-refresh of products. (https://bugs.launchpad.net/zodb/+bug/142667).

deal with changes in hashability of persistent lists in Python
2.6. (It's still a puzzle why they are hashable in realier versions of
Python, but not in Python 2.6.)

that is cleaned up at the start of a test run.

Unfortunately, the ZODB tests leave lots of temporary files behind
which can cause failures in subsequent test runs and which tend to
litter /tmp. Eventually, I want to clean that up, but, in the mean
time, I can limit the damage to the test part directory.

windows. The test author asures me that leaving the handle open wasn't
intentional.

Follow-up to r91064 to also allow deep-copied blobs to be opened (also see http://mail.zope.org/pipermail/zodb-dev/2008-August/012054.html).

  correctly, leaving the client storage in an inconsistent state.

the file storage is closed because it's internal meta data may be
invalid.