However, fixing it so far *appears* to fix a bunch of shy FileStorage
pack[Now]WhileWriting test failures whose connection to loadBefore()
isn't obvious.  It's plausible that it's a real fix for those, just
not (yet) compelling.  It seems very likely to be a real fix for very
rare failures that have shown up only in ChrisM's overnight testrunner
reports (because those did have stuff related to loadBefore() in their
tracebacks).

TRANS_HDR; also fix an import issue deriving from the creation of
ZODB.FileStorage.format. Problem pointed out by Martijn Faassen
<faassen@infrae.com>. r=jeremy

been broken by a unicode user value.

Broken objects are objects who's class has gone away, typically
because modules or classes have been removed or moved.

Broken objects are objects who's class has gone away, typically
because modules or classes have been removed or moved.

on the Zope 2 head. While I can appreciate the desire to unserstand
why register would be called by an object that has no _p_oid,
such questions should be answered in a sandbox, without breaking the
head.

revise words about registering with transactions.

If an error occurs while unpickling records, a message will be logged
and the affected records are skipped.

Remove the index file after creation. I need to look at this some
more. Why is the saved alias file incorrect? Why isn't the bogosity
recognized when the file is opened?

for each transaction.  Now they are tracked globally.

during converesion. We now skip affected records and output error
messages.

specified for an address-type value.  The tests hardwired the Linux
default (an empty string), so failed on Windows (which uses 'localhost').

Add comment explaining try/except for ImportError.
Simplify test_suite().

I can't figure out how these tests were passing in a Zope checkout.
They failed for a ZODB checkout.

update to replace ZODB 4 with ZODB 3

ExtensionClass-based base class ..." from Persistence/__init__.py.  It's
bad to see that when running tests.

This was fixed quite a while ago in ZODB 3.3, but the code appeared to
get lost in the latest round of merges.  By eyeball, I didn't detect any
other lossage in test.py.