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

I finally had to resort to os._exit, which I'm not happy about,
although I don't suppose it could do any harm for the test runner.

I wonder is a test is leaving something behind it shouldn't.

Also return the test result status as the exit status.

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

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

replaced `x` with repr(x), and replaced apply(x, y) with x(*y)

For multiple undo to succeed, the undo operations have to be
performed in a specific order.  The order was not being retained
by ZODB and was instead semi-random (the order depended on the
id() function.)  Now undo operations (as well as all
ResourceManagers) are sorted by creation order.

in the second iteration