refactoring to simplify the data structures to fix a serious memory
bug: the cache uses waaaay the heck too much.

object will properly switch to longs when over/underflowing 32-bit values

- Cache records are written in several stems.  If a process exits
    after writing begins and before it is finishes, the cache will be
    corrupt on restart.  The way records are writted was changed to
    make cache record updates atomic.

- There was no lock file to prevent opening a cache multiple times
    at once, which would lead to corruption.  Persistent caches now
    use lock files, in the same way that file storages do.

- A bug in the cache-opening logic led to cache failure in the
    unlikely event that a cache has no free blocks.

When using ZEO Client Storages, Errors occured when trying to store
objects too big to fit in the ZEO cache file.

(backport from trunk)

(backport from trunk)

This module needs to move to the Zope 2 tree.

versions of objects.

uncommitted data is placed.

  only affects zpkg.

distutils-compatible method but it failed miserably.

(hang). This was accomonied by a critical log message along the
lines of: "RuntimeError: dictionary changed size during iteration".

actively preventing it.

r77078 | gary | 2007-06-25 16:39:45 -0400 (Mon, 25 Jun 2007) | 1 line
r77010 | gary | 2007-06-24 13:19:18 -0400 (Sun, 24 Jun 2007) | 2 lines
r76977 | gary | 2007-06-23 06:57:51 -0400 (Sat, 23 Jun 2007) | 1 line
r76953 | gary | 2007-06-23 00:20:55 -0400 (Sat, 23 Jun 2007) | 1 line

Document conflict resolution. bugfix the situation in which comparing
persistent objects (for instance, as members in BTree set or keys of
BTree) might cause data inconsistency during conflict resolution.
support multidatabase references in conflict resolution.  make it
possible to examine oid and (in some situations) database name of
persistent object references so that I can add some code to
zope.app.keyreference to support these objects (so BTree conflict
resolution can happen at all when keyreferences are used).