Also updated the format to allow cache files larger than 4G in size.

ZEO, still needs to be removed.

outcome.

to exercise it under more stressful conditions.

versions.

make historical connection cache story a bit more predictable: you set a total number of historical connections, not one per serial.  Also remove "historical future" connections--I should have seen seen/remembered lastTransaction.  Now attempts to create historical future connections raise an error, as they should.

incrementally remove some version support (this time from connection and DB); add support for historical read-only connections.

Wrap the zope testrunner for ZODB in something that can be invoked using "setup.py test".  The ultimate result is:

  Ran 2510 tests in 629.115s

  OK

Although when I do:

  python bootstrap.py
  bin/buildout
  bin/test

I get:

  Ran 2821 tests with 0 failures and 0 errors in 6 minutes 55.513 seconds.

I'm not entirely sure how to account for the difference in # of tests yet.

Used and backported Python 2.5 address structures.

transaction.interfaces.

uncommitted data in (ported from 3.8).
--This line, and those below, will be ignored--

M    src/ZODB/tests/blob_packing.txt
M    src/ZODB/tests/blob_tempdir.txt
M    src/ZODB/tests/testblob.py
M    src/ZODB/blob.py

as long as we don't have a release of 'transaction' yet.

Remove the transaction package; we now have a setuptools install_requires dependency that must be satisfied to get it.

Setup.py now no longer works without setuptools installed.

To see the state of the world directly before this change was made, see http://svn.zope.org/ZODB/tags/before_transaction_remove .

  (Forward-port from 3.8 branch)

- winlock.c does not exist anymore, so do not try to compile it. This 
  only affects zpkg.

- Ignore a generated file.

(hang). This was accomonied by a critical log message along the
lines of: "RuntimeError: dictionary changed size during iteration".

preventing it.

2.4 and 2.5.

and 2.5.

document conflict resolution. bugfix the situation in which comparing persistent objects (for instance, as members in BTree set or keys of BTree) might cause data inconsistency during conflict resolution.  support multidatabase references in conflict resolution.  make it possible to examine oid and (in some situations) database name of persistent object references so that I can add some code to zope.app.keyreference to support these objects (so BTree conflict resolution can happen at all when keyreferences are used).  I will add information to CHANGES after Jim reviews (or sooner).