that we can get distutils install to munge the #! line to insert the
proper Python executable file name.  (/usr/local/bin/python would work
too, but may not be the Python version that you intended to use, so
IMO it's better to require that you use an explicit Python interpreter
when invoking the scripts before they are installed.

runzeo.py lives -- that didn't work when runzeo.py is installed in
/usr/local/bin.

activities these days.

Closes SF bug #659068.

This change adds a new method, setLocalTransaction(), to the
Connection class.  ZODB applications can call this method to bind
transactions to connections rather than threads.  This is especially
useful for GUI applications, which often have only one thread but
multiple independent activities within that thread (generally one per
window).  Thanks to Christian Reis for championing this feature.

Applications that take advantage of this feature should not use the
get_transaction() function.  Until now, ZODB itself sometimes assumed
get_transaction() was the only way to get the transaction.  Minor
corrections have been added.  The ZODB test suite, on the other hand,
can continue to use get_transaction(), since it is free to assume that
transactions are bound to threads.

+ Transaction T1 deletes some of the keys in bucket B,
  but not all of the keys.

+ Transaction T2 deletes (exactly) the keys in B that
  aren't deleted by T1.

The version of B each transaction sees is then non-empty,
but conflict resolution creates an empty bucket.  However,
conflict resolution doesn't have enough info to unlink an
empty bucket from its containing BTree correctly.

The result is that an empty bucket is left in the BTree,
which violates a BTree invariant.  The most probable
symptom is a segfault, when later & unrelated code tries
to access this bucket:  an empty bucket has NULL
pointers where the vectors of keys and values should be,
and accessing code tries to dereference the NULL pointers.

I don't know that this error has been seen in real life.
It was provoked by a randomized multithreaded simulation
program that was trying to provoke errors.  This error was
provoked frequently by that program; no other kinds of
errors have come out of it.

Fix likely bug where calling tpc_abort() after a client disconnected
did not properly clear the client's internal state about the
transaction.  The change means that tpc_abort() will never raise a
ClientDisconnected error, even when disconnected.

Added a new test that sort-of covers this case and deleted another
that was testing, in part, that you did get a ClientDisconnected
error.

run from Daemon.

Zope3/ZODB4.  Many test fixes from Jeremy (in particular,
most of the tests weren't getting run), and new tests from
Tim.  Note that the new testEmptyBucketConflict() actually
shows that a particular rare case of conflict resolution
doesn't work correctly now.  A fix for that comes next,
along with reversing the sense of this new test.

repitition and no magical guessing of type names in the datatypes.

language.

- minor markup changes

component provided with zLOG.

- add at least something of a test for the datatype

Handing off to Barry.

ZEO.Exceptions.ClientDisconnected will always be raised when a client
is disconnected.  There's also a subclass of this exception in
ZEO.zrpc.error so that it's possible to distinguish whether the error
occurred in the RPC layer or at the storage layer.