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.

1. The saving was performed in (tpc)_finish.  It is important that this
   method do as little as possible because it cannot fail!

2. The algorithm for deciding how often to save was broken. For large
   databases, for which saving periodically is desireable, the period
   was set so high that the index was effectively never saved.

It might be nice to save periodically, but doing so is tricky, since
we really don't want to do it during commit.  Until we figure out how
to do this right, it is better not to try.

In the mean time, we save on close and on pack, which is proably often
enough in most cases.

Windows. :/