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.

Objects added in transactions that were later aborted could have
_p_changed still set (https://bugs.launchpad.net/zodb/+bug/615758).

- ZEO extension methods failed when a client reconnected to a
  storage. (https://bugs.launchpad.net/zodb/+bug/143344)

repeatedly.

Added additional debugging info to try to understand what's going on
on a rare bot test failure that I can't reproduce.

sockets.

failure to deal with a test failure that occurs often in a buildbot,
but that I don't get myself *even* when running on the same machine as
the bot.

failure.

tested incorrectly for ZEO.

  When objects were added in savepoints and either the savepoint was
  rolled back (https://bugs.launchpad.net/zodb/+bug/143560) or the
  transaction was aborted
  (https://mail.zope.org/pipermail/zodb-dev/2010-June/013488.html)
  The objects' _p_oid and _p_jar variables weren't cleared, leading to
  surprizing errors.

without setting the connection.

Fixed a bug in processing invalidations. Cache last tid shouldn't be set until all of the invalidations have been processed. For this reason, we no longer set the last tid in the cache invalidate method

test thread.

Use with to simplify locking code.

The interface, ZODB.interfaces.IStorage was incorrect. The store
  method should never return a sequence of oid and serial pairs.

---------

- Database connections didn't invalidate cache entries when conflict
  errors were raised in response to checkCurrentSerialInTransaction
  errors. Normally, this shouldn't be a problem, since there should be
  pending invalidations for these oids which will cause the object to
  be invalidated. There have been issues with ZEO persistent cache
  management that have caused out of date data to remain in the cache.
  (It's possible that the last of these were addressed in the
  3.10.0b5.) Invalidating read data when there is a conflict error
  provides some extra insurance.

checkCurrentSerialInTransaction.

Add logic to allow new clients to be used with older servers.