BTree.  This came up on the zodb-dev list last week, and Steve Alexander
pointed out that the simple fix is virtually unknown in the community.
Then again, I hope the problem is virtually unknown in the wild now too.

The refcount reported for a ghost was one too small, because the code for
ghosts and non-ghosts was the same, and presumably "it's a feature" that
the code for non-ghosts deliberately lies about the true Python refcount,
in order (guessing here) to report what the count would have been if the
cPickleCache didn't exist.  But while the cPickleCache holds on to a real
reference to non-ghost objects, it does not hold a real reference to ghost
objects, so subtracting "an extra" count for all objects made it appear
that non-referenced ghosts exist in the cache (which doesn't actually
happen).

What a tangled web we weave ...

- fix typo in extension module name

testNoDamage():  Verify that the recovered .fs is in fact identical
to the original .fs.

that the number of bytes removed ends with "0".

Other tests:  if the output doesn't contain 'error', show the actual
output.

fsrecover.py:  the call to restore() was still using .serial, which no
longer exists.  Changed to use .tid.

testRecover.py:  the tests here passed despite that fsrecover wasn't
working at all.  Changed RecoverTest.recover() to eliminate its unused
arguments, and to return all the output fsrecover.recover() produces (the
output was being thrown away, unlooked at).  Added new testNoDamage(),
which feeds recovery a healthy .fs, and then looks at the output of
recovery, to verify that no errors were reported and no bytes were
removed by recovery.  Changed all the other tests to stop passing unused
arguments to RecoverTest.recover(), and to verify that error output was
produced by recovery.

XXX I'm not sure that every call to RecoverTest.recover() will actually
XXX produce an error in fsrecover.recover(), so we may get some spurious
XXX test failures here.  I'll keep my open for those.  (The kinds of
XXX damage tested are randomized, so one run doesn't prove anything.)

'pack' default value from 0 to None (this looks like the clear intent
of the code).

Note that fsrecover.py is totally broken, but testRecover.py isn't
detecting it.  I'm working on repairing both.

the first function defn.

tried to print the module docstring, but in an unreachable line.  In
case of more than 2 positional args, the code died with a mysterious
"unpack tuple of wrong size" exception; check for the correct # of args
directly instead.  Print all error msgs to stderr instead of stdout.

grammar and spelling.

    "sporadic Zope crashes"
    http://collector.zope.org/Zope/553

This is much like the test of the same name I just added to the Zope
2.6 and 2.7 branches, but reworded to use ZODB 3.3isms.  The HEAD
bucket conflict resolution code is already correct in this case,
so no other code change here -- adding this test to ensure it stays
correct.

'test left threads behind' warnings. Tests in testZEO sometimes do
that too, but that's hard to reproduce.

to zLOG other than a few comments.

This definitely broke the log analyzers pretty bad.

This probably broke the log analyzers... :(

fiddly code trying to prevent OverflowError.

conversion (this is an --all test, so the original committer probably
didn't run it).

Introduced a trivial new module (loglevels.py) to centralize creating
the custom log levels ZODB/ZEO want to use.

processing the messages because the format might have changed a little bit.

(the tests themselves still aren't being run; we need decent
save/restore behavior from the logging package to do this properly)