management of pool lock.

were not handled correctly.

fsync when commiting transactions to make sure that transaction
data are written to physical storage immediately. There is circumstantial
evidence that database corruption has been caused due to problems with
delayed write of data after Zope has flushed transaction data.

Added logic to avoid writing empty transactions. It's imaginable that
some future application might want to write empty transactions to
capture transaction meta data. If this ever becomes an issue, then
this feature would have to be made optional.

Added utility code to recover corrupted databases. Note that
the recover method is imperfect. It doesn't recover lost data. It
just repairs the file so the lost data doesn't prevent startup.

To run the recovery code:

  - cd lib/python
  - python ZODB/fsrecover.py ../../var/Data.fs

  - Restart or pack Zope, causing an index to get written

  - Undo some transactions

  - Shutdown Zope ungracefully (e.g. kill)

When Zope comes up, the index points to undone records for some
objects. This can lead to all sorts of problems. :(

To overcome this problem, we now remove the index after an
undo.

This increases the likelyhood that it will take longer to restart
next time, but reduces the chance of a bad index.

Renamed some classes to make their intent clearer.

Fixed a silly typo in zrpc.

traceback info rectified by the last, more substantive checkin...

object that has previous records.  This caused a panic on startup
because the previous record pointer did not agree with the system's
knowledge that there was, indeed, a previous record. This is a
pretty benign situation, so, I've changed the check to log a warning
of the previous record pointer is zero and there is a previous record.

instances as non-persistent.

got registered.

.__class__.   This caused acquisition wrappers to get pickled. :(

ignored and an indeterminate value used instead.

a transaction could, in rare cases cause inconsistent computations.

Also added argument to incrgc to allow more aggressive GC.

storage errors.

to get version cache settings.

when their state was loaded. :-[

moving parts.

The minimize machinery didn;t use the correct time units.

The incremental GC had some bugs that made it too conservative.

the actual caches.

to fail.