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 Seaver                                [EMAIL PROTECTED]
Zope Corporation      "Zope Dealers"       http://www.zope.com
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to