-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Peters wrote:
[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).
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?
- 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).
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. - 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). - ReleaseMaker updates changelog, version.txt, etc. and checks in. - ReleaseMaker uses 'svn cp' to create the release tag for Zope 2.8a2 (whatever it is being called).
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.
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.
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.
They should be identical, as none of the checkins on the 'five-integration' branch touched anything under ZODB. Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCSd2gGqWXf00rNCgRAkPkAJ4gZhGlb5sDAr0QlDtOPJ3N4BE+pQCfdf4W IUamIwQMwMO6HiD9YWdiVoI= =SyzX -----END PGP SIGNATURE-----