SAX stuff (that all comes with the minimum Python needed
to run ZODB now).

God knows it will get out of synch someday, but continuing to call
it version 0.3a2 is crazy.

Call it beta 1.  Recommend Python 2.3.4.  Retract the promise that ZEO incompatibilities will be fixed in
beta 1.

to the dead StandaloneZODB project at SourceForge.

sync the Zope 2 trunk with that so we can make progress on Zope 2
without waiting for ZODB 3.3 mounting/multi-database support to be
finished.

This tag was created from trunk revision 3211:

svn cp -r3211 svn+ssh://svn.zope.org/repos/main/ZODB/trunk \
              svn+ssh://svn.zope.org/repos/main/ZODB/tags/3.3.0a2

created from, dang it.

cacheMeanDeal, and cacheMeanDeac methods from the DB class.  They
were untested, undocumented, unused, and did nothing of use (the
first always returned an empty tuple, the rest always returned None).

this should be automated by zpkg, but just name it specifically for now

- the implementation is a shim around the "persistent" package, so we need that
- the tests import a function from ZODB.util

error if zope.interface is not available
(the ZODB import is not checked at all, though)

- Put horizontal whitespace around most operators.
- Split all compound statements to have one statement
  per physical line.
- Switched to augmented assignment where possible.

so just get rid of them.

distutils scripts= argument.  I misunderstood the purpose of that.

distutils scripts= argument.  I misunderstood the purpose of that.

testItemsNegativeIndex (3 instances):  repaired off-by-one glitch in loop (range(i, j, k) is always exclusive of j).

Fix bug indexing BTreeItems with negative values. Previous code assumed that idexes passed to BTreeItem_item would be negative, in practice this was not the case, and an index of -1 actually passed len(items)-1 as the index argument. Consequently, it was possible to access each item using two negative indexes (i.e., -1 and -len(items)-1). This made each item appear twice in a reverse iteration.

Code in BTreeItems_seek attempted to match the sign of the pseudoindex kept in the BTreeItems obj and the incoming index. Since this incoming index was never legitimately negative as it assumed, actually negatives passed in due to "overshooting" the first item would repeat the items again from the end. Removal of this code corrects the problem.

Unittests which provoke the error in the original code have also been added.

Zope 2 trunk with that so we can make progress on Zope 2 without
waiting for ZODB 3.3 mounting/multi-database support to be finished.

Removing the subtree rooted at ZODB/src/ZODB/zodb4/.

execute permissions.  This deals with the ZODB and ZEO ones
enumerated there.

of the most recent full backup, repozo.py failed to find the appropriate
files, erroneously claiming

    No files in repository before <specified time>

Repaired that.  Also made it much more robust against "junk files" the
user may create, or leave behind, in the backup directory.  Added test.

but nothing in scripts/tests/ does.  It failed before the
earlier (today) fixes to repozo.py, and passes now.
Better Than Nothing -- which is what we had before.

Under exceedingly rare conditions, a timing hole made it
possible for a second open() call on a database to block for an
arbitrarily long time.  This accounts for the intermittent
failure of a thread to make any progress after 5 minutes in
checkConcurrentUpdates1Storage.

We intend to get rid of most of this delicate lock
business, but before then the test failures are still
hurting me.

Collector #1330:  repozo.py -R can create corrupt .fs.
When looking for the backup files needed to recreate a Data.fs file,
repozo could (unintentionally) include its meta .dat files in the list,
or random files of any kind created by the user in the backup directory.
These would then get copied verbatim into the reconstructed file, filling
parts with junk.  Repaired by filtering the file list to include only
files with the data extensions repozo.py creates (.fs, .fsz, .deltafs,
and .deltafsz).  Thanks to James Henderson for the diagnosis.

This fixes it, based on an approach suggested by Toby
Dickenson.  The triggering condition wasn't entirely
sane, so was very rare:  a persistent object with a
__del__ method that referenced an attribute of self.

scan_gc_items():  Look at persistent objects accessed
while this is running at most once.

New test checkMinimizeTerminates():  This spawns a thread
that will in fact run forever if you don't recompile
cPickleCache.c.  The test suite will keep running, but
checkMinimizeTerminates will fail, and all future calls
to cacheMinimize() will be effectively ignored (so other
bad things may happen as a result).

why the sleeps are needed.  The explanation (and the
sleeps) didn't make sense -- must be left over
from a cache implementation before my time.

Added long-requested docs about mutating BTrees while iterating over them.  Will regen the .pdf and .html later (I want to add more .tex docs first).