[Tres Seaver] ...
Most of that work has been done on the trunk. The 'five-integration' branch changes consist largely of:
- Setting up an 'svn:external' link to the Zope X3 3.0 repository (which is on a branch, pruned to include only the packages which were actually released with 3.0).
Just noting that this may create new but short-lived problems for developers on Windows (can't tell for sure until I try it; has to do with PuTTY's "symbolic names", and the unlikelihood that any Windowshead has "svn.zope.org" set up as a symbolic name now).
- Importing the Five product.
- Un-monkey-fying Five's monkey patches.
As soon as we settle the question of how ZODB gets stitched in (I prefer the 'svn:external' mode myself, but that is just a preference), that branch should be easily merged.
Since Zope doesn't "own" ZODB, I don't see how merging the branch has anything to do with how ZODB gets stitched in. Stitching in a _new_ ZODB is my problem, after the branch is merged (& I need the merge to happen first, so that Zope3 (lib/python/zope) packages show up on the trunk -- ZODB 3.4 can't work without them). AFAICT, no stitching of ZODB took place when five-integration branch was created. For example, the log message for Zope/branches/five-integration/lib/python/ZODB just says it was copied from Zope/trunk:29468. IOW, it just copied over the version of ZODB that happened to be in Zope trunk at the time the five-integration branch was created. If people then made _changes_ to ZODB code on five-integration, they should not have, and it will create problems. But if they didn't, the ZODB code on five-integration branch and Zope trunk should still be identical, in which case no code in any of the 9 ZODB directories should have any effect on the merge. IOW, ignore ZODB entirely: if the tests pass on the branch, they should continue to pass on the trunk after the merge, since the ZODBs on branch and trunk should be exactly the same right now.