an external garbage collector with ZEO.  When objects were deleted
  from a storage, invalidations were sent to clients. This makes no
  sense.  It's wildly unlikely that the other connections/clients have
  copies of the garbage.  In normal storage garbage collection, we
  don't send invalidations. There's no reason to send them when an
  external garbage collector is used.

This is added insurance on
https://bugs.launchpad.net/zodb/+bug/665452.
In particular, because we saved dups, the damage persisted, requiring
a process restart to clear.

  When a transaction rolled back a savepoint after adding objects and
  subsequently added more objects and committed, an error could be
  raised "ValueError: A different object already has the same oid"
  causing the transaction to fail. Worse, this could leave a database
  in a state where subsequent transactions in the same process would
  fail.

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

- Moved 3.9 changes to HISTORY.txt.

- Consolidated 3.10 pre-release entries.

- Removed 3.10 (bug fix) entries for fixes that were in 3.9, so the
  3.10 changes are from 3.9.

- Changes to suppprt IPv6 broke a fix for a problem on Mac OS X that
  could cause a server to stop accepting connections.

----------

- When a pool timeout was specified for a database and old connections
  were removed due to timing out, an error occured due to a bug in the
  connection cleanup logic.

- When mulri-database connections were no longer used and cleaned up,
  their subconnections weren't cleaned up properly.

- On some systems, using an empty string in a server address of a ZEO
  client led to a socket error. Now, ZEO clients treat '' as an alias
  for 'localhost'.

- When using multi-databases, cache-management operations on a
  connection, cacheMinimize and cacheGC, weren't applied to
  subconnections.

of provoking the buildbot test failure that I hope I just fixed. :)

- ZEO didn't work with IPv6 addrsses.
  Added IPv6 support contributed by Martin v. Lowis.

- A file storage bug could cause ZEO clients to have incorrect
  information about current object revisions after reconnecting to a
  database server.

Also added a locking/transaction ordering test.

Sorry, need to change the version number to represent something closer to the actual one, otherwise developing the code in combination with other software with a ZODB>=3.9 dependency doesn't work

Be nice and use loadable test data in the new check_checkCurrentSerialInTransaction test. This allows the tempstorage tests to pass again, which directly reuse the BasicStorage protocol tests.

- Logrotation/repoening via a SIGUSR2 signal wasn't implemented.
  (https://bugs.launchpad.net/zodb/+bug/143600)

Needs windows test.

- Changes in way that garage collection treats dictionaries in Python
  2.7 broke the object/connection cache implementation.
  (https://bugs.launchpad.net/zodb/+bug/641481)

- Object ids created in a savepoint that is rolled back wren't being
  reused. (https://bugs.launchpad.net/zodb/+bug/588389)

  The verbose mode of the fstest was broken.
  (https://bugs.launchpad.net/zodb/+bug/475996)

  Setting _p_changed on a blob wo actually writing anything caused an
  error. (https://bugs.launchpad.net/zodb/+bug/440234)

there aren't any transactions.  Now a string of 8 nulls (aka "z64")
is specified.