When an integer too large to fit in a 32-bit integer was provided as
  a 32-bit-integer BTree key or value on 64-bit machines, an
  OverflowError was raised. Now a TypeError is raised.

than before).  It's possible that process shutdown after updating
lastTid but before invalidating the current record could explain some
problems we've seen on restarts.

(This change is made irrelevent by later changes.)

- Passing keys or values outside the range of 32-bit ints on 64-bit
  platforms led to undetected overflow errors. Now these cases cause
  Overflow errors to be raised.

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

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

- BTree sets and tree sets didn't correctly check values passed to
  update or to constructors, causing Python to exit under certain
  circumstances.

- BTree sets and tree sets didn't correctly check values passed to
  update or to constructors, causing Python to exit under certain
  circumstances.

with Python optimization turned on.

- The standard storages, FileStorage, ClientStorage, DemoStorage, and
  MappingStorage now allow the version argument to history and load to
  be ommitted.  This is to make it easier to write application code
  that works with ZODB 3.8 and later versions, which don't support
  versions.

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