- remove old XXX comments: we have added information on schema, and
  no, we really don't want to talk about "handlers" -- they're evil

context

it, and the only value a subclass ever set it to was None.

FileStoragePacker's constructor mean.

  <key name="+">; keys need to be provided for each default value
- fix bug in converting an empty section that contained a
  <multikey name="+">
- document <default> element in reference manual and DTD
- more tests

a two-state flag, with possible values z64 or None -- eh?).

record's "status byte" are and mean.

Make _added_during_commit a regular instance variable.  Don't use
try/finally to reset it; just clear it at the start of a transaction.
XXX There was a test that needed to be removed, but it seemed to be
just a shallow test that try/finally was used.  Can't see any feature
that depends on specific of error handling: The txn is going to abort.

Remove unused _opened instance variable.
Split commit() into two smaller parts.
Get rid of extra manipulation of _creating.
Don't look for _p_serial of None; z64 is now required.
Undo local variable aliases in subtransaction methods.

Also, trivial change to pickle cache API -- get() works like dict get().

with

    CorruptedError:  ... transaction with checkpoint flag set

on my box when doing the ZEO flavor of FileStorage.  This is like the
other pack-while-writing tests, but uses only 1 client thread that does
twice as much, and packs repeatedly for so long as that thread runs.  I
usually see it fail before the fourth pack attempt.

This makes the ZEO flavors of the tests much more likely to complete
without a "thread still alive" failure.

Forcing the output even when a test passes is interesting on my box.
When ZEO is involved, a single ClientThread tends to run all the way to
completion before another ClientThread manages to sneak in -- apart from
their first transactions, it's as if we ran one thread, then started the
next after the first finished (etc).  When ZEO isn't involved, threads
take turns.  When I see failures, they involve ZEO.  It's possible that
30 seconds just isn't long enough to wait on this box.

Drop several possible tasks that didn't seem relevant,
e.g. _p_independent() tests elsewhere should cover it just fine.

It's clear in hindsight that the connection only loads non-current
revisions for objects that have been invalidated.  Thus, we never need
to track them to invalidate stale objects; they'll be invalidated
anyway.  And loadBefore() will never return a current revision,
because it would only be called if the current revision could not be
used.

an unexpectedly live thread at the end.  That's been happening forever,
but never when I stare at it, and the more I stare at those tests the more
baffled I am that it ever fails this way.  So the point here is to get
more clues when nobody is staring at it <wink>.

exception), explicitly close the storage passed to it, then re-raise
the exception.  Otherwise the storage remains open.  Turns out that
accounted for why test_zeo_config left a ConnectThread daemon thread
running (Zope3's test.py has been pointing that out for a loooong time).

isImplementedByInstancesOf to implementedBy
  isImplementedBy            to providedBy