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.

Share backpointer implementation between _loadBack() and
_loadBackPOS() to avoid duplicate code.

Simplify interface between FileIterator and RecordIterator.  Don't
pass unused arguments and don't pass nested tuples.

Use global variables to hold trans and data struct formats.

Reformat several docstrings.

Add whitespace to RecordIterator so that I can read it.

This change is an untested improvement.  If some object is in the
index but unloadable for some reason, report it along with the
traceback.  When possible, report what objects refer to the
un-loadable one.

dangle.py script that creates one.

It appears the initialization was accidentally removed in rev. 1.51.
Add comment about why percachedel is not initialized here.

supported.

passed around and revised for almost a month.)  This is accurate, but
not necessarily complete.