on others.

  improved in the case that servers are restarted.  Before, if
  transactions were committed after the restart, clients that were up
  to date or nearly up to date at the time of the restart and then
  connected had to verify their caches.  Now, it is far more likely
  that a client that reconnects soon after a server restart won't have
  to verify its cache.

- Fixed a serious bug that could cause clients that disconnect from and
  reconnect to a server to get bad invalidation data if the server
  serves multiple storages with active writes.

invalidation queue.

 - added test for custom openDetached() class

 - added notice to history txt that zodb 3.8 now contains blobs :)

These files were missing:

  BTrees/Development.txt
  ZEO/scripts/README.txt
  ZODB/scripts/README.txt
  ZODB/scripts/referrers.txt

 - moved setuptools import in setup.py before distutils import to allow
   setuptools to apply its patches

add missing file and fix setup.py so the error would have been caught when I ran the tests before the previous checkin

  all be accessed with those names in the modules (e.g.,
  BTrees.IOBTree.BTree).  This is in addition to the older names (e.g.,
  BTrees.IOBTree.IOBTree).  This allows easier drop-in replacement, which can
  especially be simplify code for packages that want to support both 32-bit and
  64-bit BTrees.

- Describe the interfaces for each module and actually declare the interfaces
  for each.

- Fix module references so klass.__module__ points to the Python wrapper
  module, not the C extension.

(For now, we're retaining compile-time support for making the
   regular integer BTrees 64-bit.)

the main method call needs to be lowercase, otherwise the call will raise a TypeError: Main() takes no arguments (2 given)

It isn't actually a script but it is used in the same spirit.  Maybe
it will be a script someday.

(Merged from 3.7 branch.)

These are the ZODB part of the patches I posted to
http://www.zope.org/Collectors/Zope3-dev/655 with an additional import cleanup.
The issue was silent for over 2 weeks.

Also my attempts at subscribing to zodb-dev or sending a message there
dissapeared were doomed;)

I'm fully willing to revert this if someone has an issue with it.

    ------------------------------------------------------------------------
    r70059 | jinty | 2006-09-08 16:26:44 +0200 (Fri, 08 Sep 2006) | 1 line

    Forgot the NEWS entry. Hope I did it right.
    ------------------------------------------------------------------------
    r70053 | jinty | 2006-09-08 14:43:26 +0200 (Fri, 08 Sep 2006) | 1 line

    Clean up wierd import dance with ZODB. This is unnecessary since the transaction module stopped being imported in ZODB/__init__.py in rev 39622.
    ------------------------------------------------------------------------
    r70051 | jinty | 2006-09-08 13:24:45 +0200 (Fri, 08 Sep 2006) | 1 line

    Add the ability to ask a transaction if it has been doomed i.e. isDoomed().
    ------------------------------------------------------------------------
    r70050 | jinty | 2006-09-08 13:13:06 +0200 (Fri, 08 Sep 2006) | 1 line

    Add the doom() function to transactions. Look at tests/doom.txt for more info.
    ------------------------------------------------------------------------

problem reported on zodb-dev:

http://mail.zope.org/pipermail/zodb-dev/2006-August/010343.html

Added a new invalidateCache protocol for DBs and Connections to
invalidate the entire in-memory caches.  This is used when ZEO clients
reconnect.

test for it.

explicitly flush output to make sure we see test results.

ClientStorage could be in either "sync" mode or "async" mode.  Now
there is just "async" mode.  There is now a dedicicated asyncore main
loop dedicated to ZEO clients.

This addresses a test failure on Mac OS X,
http://www.zope.org/Collectors/Zope3-dev/650, that I believe was due
to a bug in sync mode. Some asyncore-based code was being called from
multiple threads that didn't expect to be.

Converting to always-async mode revealed some bugs that weren't caught
before because the tests ran in sync mode.  These problems could
explain some problems we've seen at times with clients taking a long
time to reconnect after a disconnect.

Added a partial heart beat to try to detect lost connections that
aren't otherwise caught,
http://mail.zope.org/pipermail/zodb-dev/2005-June/008951.html, by
perioidically writing to all connections during periods of inactivity.

port that nothing's listening on.

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

o Forward-ported from 3.4 branch.

I'm not particularly proud of the tests I wrote.  It's way to hard to
write tests for ZEO.  Without a lot of white-box trickery, nothing can
be tested without making network connections, which is insane. ZEO's 
architecture needs to change.