-----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 [EMAIL PROTECTED]
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-----
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
