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

have not been initialized (as can happen when doing a deep copy of a
blob object)

a possible ordering problem for invalidation messages.

This was motivated by code inspecition during merge of an earlier
refactoring to the trunk.  The refactoring also simplifies the code
and probably makes it a tad faster.