sync() call back in to make it clearer.

and increase the sleep time per failing loop iteration.  The hope is
this will allow the test to pass on slower and/or "too busy" machines.
I can't test that, though, since I couldn't get the test to fail at
all on a Windows or a Linux box.

although ZODB doesn't.

the pickle shown is full of unprintable characters.

attribute.

The related txn_mgr spelling of various method arguments is
now deprecated, and a "transaction_manager" spelling is added.

latter to Jim's development version.  Hardest part turned out
to be teaching ZODB's setup.py how to "build" this version of
zope.testing (it has a lot of packages in a test directory,
where the latter is not itself a package).

Incidentally repaired an oversight in building zope.interface
too.

These config file keys changed:

section    key              was             is
-------    ---------------  --------------  -------------------------
zeo        address          socket-address  socket-binding-address
zeo        monitor-address  socket-address  socket-binding-address
zeoclient  server           socket-address  socket-connection-address

Use the same tag Zope trunk (2.8) is using.

A patch from Mark Hammond to repair a new Windows-specific
gimmick in ZEOServer.setup_win32_signals().

This gets called "in the middle" of the test, if specified.
ZRS 1.5 uses this to pass a callback that arranges to start a
ZRS secondary then.  ZRS had its own copy of this test, but
it's a miserable & messy test, and the copy it had failed in
5 different places when using ZODB 3.4 (it had gotten way of
synch with changes since ZODB 3.2).

Also removed all traces of the bizarre _x_dostore() method.
Not sure what that was about, but if the comments were right
we don't care about ZEO 1.0 anymore.

between old logging code and the use of Python's logging
package.

ZODB/tests/TransactionalUndoStorage.py, _exercise_info_indices():
Jeez Louise, the new tests I added for undoInfo+undoLog work fine
in ZODB, but break the ZRS tests(!).  They close the DB "too soon",
and in one of the ZRS scenarios that leaves a recovering secondary
without a primary to recover from.

Repaired, + new tests.

Irony:  While these are the only accurate docs that
exist, FileStorage doesn't actually implement it this
way.  Fixing that is the next step.

releases" -- had become impossible to follow.

There are no tests for this.

If a threaded transaction manager ever passed None to
the Transaction constructor's `synchronizers` argument, then
synchronizers registered later in the same transaction
were invisible to the transaction, and so their afterCompletion()
methods wouldn't get called when the transaction ended.