I've removed all the details about Python versions prior to 2.3 and
Berkeley before 4.1.25.  I also removed all the configuration
instructions.  You "just" use the standard zconfig mechanism, which
may or may not be documented elsewhere.

and set it in more places

an older ZConfig API which has not been supported for some time

I think it's safe to lose the revision history for these files.
setup.py is a copy of ZODB3/setup.py with all the paths edited.
test.py is a copy of ZODB4/test.py with no changes.

trouble here on Windows, due to the poor granulatiry of Windows time.time()
feeding into pack-time selection in this test.  Moved the snooze() from
before pack time selection to after it, which appears to be a sufficient
fix; this can't hurt Linux, because the snooze() calls aren't needed at
all there (but don't hurt either).

for a redundant pack.

"Yow!" here anymore <wink>.

Also remove some unused imports and a somewhat irrelevant comment.

I don't really understand why this change and the last one to
runzeo.py have their apparent effects, but the tests work and the -m
option to runzeo.py works.

Noted by Jon Dyte.

Bug fix from Jon Dyte.

The comment long ago fell out of synch with the code.

The Connection class inherits from the ExportImport mixin, but they
had an arm's length interaction.  Restructure the code to provide
direct interaction via the _import attribute.

Remove the more general onCommitCallback() method.  It was only used
by ExportImport.

A lot of cosmetic changes to ExportImport:
    - don't make local variables out of attribute lookups
    - avoid local variable names that shadow builtins
    - prefer isinstance() to type comparisons
    - prefer absolute imports to relative imports

The server was sending all the invalidations from the queue, not just
the ones that were later than the requested tid.  This didn't affect
correctness of the cache, but did cause it to throw out valid data.

Add test case to verify that getInvalidations() returns only what is
expected.

Bug fix candidate.

ways, but unittest never notices this because the tests always fail in
a thread unittest doesn't know anything about.  Changed ClientThread
to derive from the MTStorage tests' TestThread, which arranges to re-raise
a thread-death exception in the main thread.  Tested "by hand", via
temporarily forcing fatal thread exceptions in all the Pack[Now]WhileWriting
tests; unittest did notice those now.  So, when this happens again in real
life, we'll no longer be fooled by test runner reports claiming that
everything passed, and then frustrated by not even being able to tell
which test failed (you can't tell from the isolated thread traceback(s)
wading in the sea of testrunner dot output).

available