considered "complete".

pointed out, interpolation is a bad name for this, since it implies something
different.

interesting root reachability properties.

and eliminate default argument hack.

Remove useless register_subsystem() calls.
Define PackError instead of raising string exception.
Remove unused _stuff argument from load().
Remove unused tid argument from _txn_undo_write().
Replace seek() and unused read()s with single read().
Remove unused local variables.

Also, add sanity checks in _getVersion() and _getSerial().

log:

    Fix an old bug in poll().  When a signal is handled while we're
    blocked in select(), this will raise select.error with errno set
    to EINTR.  The except clauses correctly ignores this error, but
    the rest of the logic will then call read() for all objects in
    select's *input* list of read file descriptors.  Then when an
    object's read_handler() is naive, it will call recv() on its
    socket, which will raise an IOError, and then asyncore decides to
    close the socket.  To fix this, we simply return in this case.

Rather than incorporating a fixed copy of asyncore.py in Zope2 and
ZODB3, I'm incorporating a fixed copy of just asyncore.poll() in this
file, since we already have a copy of asyncore.loop() here.

It looks like a bogus file position (0) was getting passed to
_getVersion(), which was returning random data for the version.

XXX Need to review this patch carefully to see why the problem was
never noticed before.  Need to add a GB unit test.

(__init__.py still makes format_exception available; is this needed?)

being hashed out on the ZODB3-deadlock-debug-branch, so there's no
need to let the trunk test suite keep failing.

There are some cases, can't recall exactly what they are, where a
single ref is returned instead of a ref, class info tuple.

must've used this to disable the exception handling temporarily to
debug the exception formatting machinery, and forgotten to re-enable
it before checking in.

Unfortunately, this made it into the ZODB 3.1 release, making this a
3.1.1 backport candidate.

config parameters at once.

Add (commented-out) print statements showing progress.

Added a new test: checkMultiStorageTransaction().  This tests for the
deadlocks that we've seen when multiple appservers do transactions
involving multiple ZEO 2.0 storages.  It also nicely tests the timeout
feature that Jeremy added to StorageServer.

WARNING: with the current ZEO code, this occasionally hangs.  That's
the point of this test. :-)

If a transaction takes a long time to complete after it has the
storage lock, close the connection and abort the transaction.  The
abort may cause the client to be hosed.

XXX There should be a configuration option to enable / disable this
feature.  That should be done before too long.

When a transaction takes a long time to complete, it is often a sign
of deadlock involving multiple storages.  Until the possibility of
deadlock is eliminated, this feature will prevent an entire ZEO
cluster from deadlocking (on writes).

(Re-applying a lost change.)
Some storages get confused by tid == 0.

checkCreateObjectInVersionWithAbort().

generally useful for storages that support the iterator protocol.
Note that copyTransactionsFrom() implicitly tests restore().

tests for proper behavior when aborting a version in which an object
was created.

As the comment said:

    Not really necessary in production code... disable this before
    release, providing noone has been reporting and RuntimeErrors
    that it uses to report problems.

via a convenient local variable.

documentation.

XXX This creates a new requirement: If a store implements restore(),
it's iterator() implementation must support the data_txn option.

XXX This version fails silently when it should be able to write a
backpointer, but can't.

Some storages get confused by tid == 0.

The Record() object now has a data_txn attribute that is either None
or the id of the transaction that contains the data used by the
current record.  Example: When transactionalUndo() modifies an object,
it typical creates a new data record that points at the transaction
before the undo.  The new record contains the same logical data as the
record it refers to.  (For consistency purposes, this is a stronger
claim than that the pickles in two different data records are the
same.)

Add a test of the new iterator() feature in TransactionalUndoStorage.