svn+ssh://pythondev@svn.python.org/python/branches/tnelson-trunk-bsddb-47-upgrade
........
r64368 | trent.nelson | 2008-06-17 23:13:44 -0500 (Tue, 17 Jun 2008) | 1 line
Initial commit of work pertaining to switching the Windows build from Berkeley DB 4.4.20 to 4.7.25. Note that I've deprecated the standalone '_bsddb44.vcproj' in lieu of adding the sources in a separate folder to the _bsddb project. This was a conscious decision and actually makes everything far more easier to manage. With this approach, entire test suite passed straight off the bat. Well, almost -- the timeout in bsddb/test/test_replication.py needed bumping up a little -- 2 seconds was too short. 10 seconds seems to be fine for me, but I'll make sure Jesus verifies. More documentation to come once I've been able to test out this approach on the buildbots (hence keeping the changes in a separate branch for now).
........
r64369 | trent.nelson | 2008-06-17 23:19:12 -0500 (Tue, 17 Jun 2008) | 1 line
Bump Berkeley DB version from 4.4.20 to 4.7.25.
........
stuff in and clean it up afterwards regardless of the result.
* Get rid of duplicate list of test modules to run, they're maintained
within test_all now.
* Print the BerkeleyDB version to stderr when running test_bsddb3 to
help buildbot problem diagnosis.
not appear to be a new bug, its just that the test coverage went up
recently exposing it. (I verified that by testing this test code on
an older Modules/_bsddb.c)
run the test simultaneously. The simplest thing I found that worked
on both Windows and Unix was to use the PID. It's unique so should be
sufficient. This should prevent many of the spurious failures of
the automated tests since they run as different users.
Also cleanup the directory consistenly in the tearDown methods.
It would be nice if someone ensured that the directories are always
created with a consistent name.
keyword argument whenever possible to avoid bugs and confusion. (dbtables.py
line 447 self.db.get using txn as a non-keyword was an actual bug due to this)
string key (and probably a few other situations with string keys).
This was reported with a patch as pybsddb sourceforge bug 1708868 by
jjjhhhlll at gmail.
The problem is that _DB_get_type() can't be called without the GIL
because it calls a bunch of PyErr_* APIs when an error occurs.
There were no other cases in this file that it was called without the GIL.
Removing the BEGIN/END THREAD around _DB_get_type() made everything work.
Will backport.
in BerkeleyDB >= 4.2 it tried to construct a list out of an uninitialized
char **log_list.
feature: export the DB_ARCH_REMOVE flag by name in the module on BerkeleyDB >= 4.2.
between a TestCase instance, the database it opened (or a cursor to a
database) and a bound method as a registered database callback, and a lack
of GC-handling in bsddb caused the TestCases to linger. Fix the test, for
now, as backward compatibility makes adding GC to bsddb annoying.