Clean up formatting to 80 cols and add a restriction noting that BlobFiles can't live beyond the transaction in which their "open" call was invoked.

Stop silent data loss in some BTree cases where a transaction adds
a new key to a bucket while a concurrent transaction deletes all
keys from the same bucket.

Still needs porting to ZODB trunk and to 3.2 line.

 - Explicitly allow the different modes to be selected when opening a blob file.

 - added clean(er?) handling on cleaning up blobs on transaction boundaries and
   beeing more careful not to cause harmful states when leaking BlobFiles out
   of threads/transactions (e.g. to Medusa)

 - Added Import/Export support. Actually this is even backwards compatible.

Various Zopes probably need changes too (to avoid the new deprecation
warnings).

 - merged from head
 - added configuration methods to configure a blobfilestorage
 - made stuff work ;)

Jim (Fulton) points out that it's not entirely clear that
the new format can't be read by older ZODBs, and Tim doesn't
think it's worth the bother to find out for sure.

Added news blurbs about fsIndex improvements, and about that
.index files written by 3.4 won't be readable by earlier ZODBs.

test.py ran these tests ran after "setup build_ext -i", but
not after "setup build".  Repaired by teaching setup.py to
copy more stuff out of the relevant directories.

There's a mystery:  the tests for it appear to run after
"build_ext -i", but not after "build".  But that appears
to be true for the long-stitched-in zope.interface too.

trunk, so remove the branch (it's an attractive
(OK, maybe not all _that_ attractive <wink) nuisance
now).

This introduces a "multi-database" concept (a simplification
of Jim's Wiki proposal), and adds many interface definitions.

Work done during the PyCon 2005 ZODB sprint, by Christian
Theune, Jim Fulton and Tim Peters.

 - Started work on documenting the storage interface(s)
 

Redid the start of the test to build from an empty
.databases dict, since I expect that will be how this
gets used in reality.

Added some tests showing the keys in the mappings.

No commit message

Add a record iteration protocol to FileStorage.  You can use the record iterator to iterate over all current revisions
of data pickles in the storage.

In order to support calling via ZEO, we don't implement this as an actual iterator.  An example of using the record iterator
protocol is as follows:

storage = FileStorage('anexisting.fs')
next_oid = None
while 1:
    oid, tid, data, next_oid = storage.record_iternext(next_oid)
    # do something with oid, tid and data
    if next_oid is None:
        break

The behavior of the iteration protocol is now to iterate over all current records in the database in ascending oid order, 
although this is not a promise to do so in the future.