Thanks for this!
Not required, so long as I get to thank you for finishing it ;-)
Looks like that test failure is incidental and not symptomatic of
changes made to ZODB. I think Tres may have said that it can be
fixed by merging in a fix from the Five HEAD, but I don't know this
for fact first-hand.
I'm sure that failure will go away by itself when you're working on
the trunk instead of the branch. What I'd do now:
- Check out Zope trunk.
- Merge the branch into your trunk sandbox, and forget the branch.
- Fix merge conflicts. I got one, in datatypes.py, and I didn't know
immediately what to do about it so stopped there. You'll have
better luck ;-). Note that, under SVN, after you fix a
have to do "svn resolved path/to/conflicted/file"; that's a gimmick
to make sure you don't forget about conflicts.
- "svn up" to make sure you've got all the externals the merged
files point at.
- "svn up" from time to time thereafter, to suck in other trunk
as they get made.
- Check it in when it's stable.
- If it takes longer than expected, make a _new_ branch _from_
your merged-into-trunk local trunk sandbox. (That's easy: make a
branch directory, "svn switch" to it from your local merged trunk
sandbox, and "svn commit" -- all done).
It's encouraging that most of the tests pass but there are a paucity
of tests that specifically test Zope 2 multidatabase-based mount
points. There are a few convincing-looking decoys in
Products.ZODBMountPoint.tests but I think I'll need to create a few
more to get the warm and fuzzies before doing the merge.
As above, you can do a _local_ merge right away. This would save you
from other decoys (like the DeprecationWarnings that would no longer
exist if you were using the trunk instead of the brach, and the
failing-on-branch-but-not-trunk Five test).
I recall that, historically, the Zope tests never failed when Zope
mounting was in fact broken, so a fat +1 to beefing test coverage
I have this on my plate for Wednesday evening.
Understood; there really isn't any good TV on Wednesdays anymore ;-)