[Tres] ...
I'll have to take your word for that; are you saying that 'svn:external' doesn't work by default in the windows SVN clients?
Crossed in the mail; no problem here. ...
OK, that works for me. AFAIK, the branch should be ready to merge "whenever"; all the recent work on it has been to merge fixes which had already been applied on the trunk. How does this sound for a recipe:
- ReleaseMaker merges the 'five-integration' branch to the trunk, and tests it.
Check.
- ZODBGuru uses 'svn rm' to zap the current ZODB on the trunk, replacing it with an 'svn:external' link to your ZODB 3.4 tag; and then tests it (could be an 'svn cp', but I don't see any benefit to maintaining a Zope-specific fork).
My problem. It will certainly be done via 9 "svn switch"s on my local machine first. As explained elsewhere, there are several other possible sources of integration problems here, and I can't know about those before actually trying it. It's possible, e.g., that I'll need to change ZODB 3.4 to worm around them, or switch ZODB to using a different ZConfig, etc. Can't predict here.
- ReleaseMaker updates changelog, version.txt, etc. and checks in.
Check.
- ReleaseMaker uses 'svn cp' to create the release tag for Zope 2.8a2 (whatever it is being called).
Check. ....
The goal for that branch was to do *only* stuff which had to do with landing Five / ZopeX3.0; no other changes were supposed to land there. Any non-Five-specific work was supposed to happen on the trunk.
Crossed in the mail again; I confirmed this is so for the zdaemon, ZConfig and nine ZODB directories. ... Just ran the five-integration branch tests on Windows. Two failures, which are repeats of longstanding trunk failures on Windows: http://www.zope.org/Collectors/Zope/1728