committing.

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

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

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

 Process exits or database closes could cause ZEO caches to have
 incorrect data due to a problem in the way invalidations were processed.

- Shutting down a process while committing a transaction could cause
  ZEO client caches to have invalid data.  This, in turn caused stale
  data to remain in the cache until it was updated.

  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.

between logs and ints.

- Conflict errors didn't invalidate ZEO cache entries.

- If a ZEO client process was restarted while invalidating a ZEO cache
  entry, the cache could be left in a stage when there is data marked
  current that should be invalidated, leading to persistent conflict
  errors.

- Corrupted or invalid cache files prevented ZEO clients from
  starting. Now, bad cache files are moved aside.

- Invalidations of object records in ZEO caches, where the
  invalidation transaction ids matched the cached transaction ids
  should have been ignored.

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

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

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

cause a ZEO server to stop accepting connections, due to a failure
to catch errors in the initial part of the connection process.

The failure to properly handle exceptions while accepting
connections is potentially problematic on other platforms.

Fixes: https://bugs.launchpad.net/zodb/+bug/135108

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

set object state when objects implemented _p_invalidate methods
that reloaded ther state (unghostifiable objects).

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

set object state when objects implemented _p_invalidate methods
that reloaded ther state (unghostifiable objects).

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

install and use the mkzeoinstance script. :)

optimized Python. :(

Added back the second test condition, otherwise the test wasn't failing on some platforms without the actual code change

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

Much thanks to Hanno Schlichting and Nikolay Kim for coming up with
the patch.