(equivalent to revision 25293 on the ZODB 3.3 branch, but not a merge, since
the files were added separately after the branch was made)

this was in Releases/ZODB3/ on cvs.zope.org

worker thread creates could cause mysterious exceptions in
*later* tests (when running all the tests, they appeared
to come out of checkDetail, which runs right after
checkMinimizeTerminates).  Changed the CantRidOfMe class
so that instances of the class *can* be gotten rid of,
keying off a new module bool.  The checkMinimizeTerminates
worker thread uses this to defang the objects after the
body of the test has completed.

In replace(), print feedback to stderr, since fileinput
hijacks stdout.

release, tried to make this script much more robust.  Use
r-strings for regexps.  Junk unnecessary code that a Unixhead
probably thought was needed for Windows (replacing forward
slashes in filepaths -- Windows accepts those too).  Made
the search criteria for NEWS.txt much looser (this is the
one we seem to blow most often).  Changed replace() in
several ways:  only replace the first occurrence of the
pattern (we never need more than that, and looser searches
are dangerous when replacing all occurrences); provide
feedback on everything done; if the pattern isn't found
at all, print a noisy msg saying so.  Completed the list
of modified files in the module docstring.

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.

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.

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.