Non-ghostifiable (persistent classes) objects load their state right
  away -- even before they are placed in the cache.  This causes a
  problem if the object's state has a (direct or indirect) reference to
  it. Added a pre-cache that allows the connection to return objects
  already being loaded when necessary.

  apply the garbage collections on those connections in the pool that are
  closed. (This fixed issue 113932.)

can cause signidficant delays, especially on systems with very
course-grained sleeps, like most linux systems.

Extracted from rev 73871 in svn://svn.zope.org/repos/main/ZODB/trunk/src/ZEO
(Jim Fulton did the extracting and handed me the diff on IRC).

No commit message

o Most notably, ZEO.ClientStorage (http://www.zope.org/Collectors/Zope/2016).

o Forward-ported from 3.4 branch.

PersistentMapping was inadvertently pickling volatile attributes (http://www.zope.org/Collectors/Zope/2052).

GCC 4.0.x.

See http://www.zope.org/Collectors/Zope/2027.

be backported further.)

This _should_ have been done for 3.6.0, but wasn't.

Also move to current zope.testing, for the heck of it.

require Python 2.4.1+.

Bring Zope info up-to-date in README.txt, and
recommend Python 2.4.2.

Updating this info in PACKAGE.cfg is needed to
build a release tarball.

due to exceeding pool_size available connections, clear its
cache right away.  Because such a connection can never be in
the open state again, hanging on to resources in its cache is
just wasteful.  This was reported as "a problem" on zodb-dev
recently, although it's unclear how the poster got into a state
where it mattered so much.

_setstate():  An MVCC optimization was inadvertently disabled by
fixes for ZClasses.  Repaired.

Elsewhere, repaired English in comments.

Repair typo in exception message.

thread simplifications in Connection._invalidated handling.
Thanks to Florent Guillaume for noticing!

  tools need to perform minimal logging configuration themselves. Changed
    the zeoup script to do so and thus enable it to emit error messages.

Nail the type of oids, as agreed ;-) to in

 http://mail.zope.org/pipermail/zodb-dev/2005-March/008593.html

Deleted news from ZODBs 3.5 and earlier; the news file was
getting ridiculously large.

- fixed the API of the pop() method on PersistentDict and PersistentMapping
- no longer try to find pop and popitem on UserDict as all supported
  Python versions have them
- added a test for the default argument of pop()
- added a NEWS.txt entry about pop()

distribution now.  Explain the differences.  Removed the
business about fiddling PYTHONPATH, because it shouldn't
be needed (and isn't for me ;-)).