> 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.
> - 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.
> - ReleaseMaker uses 'svn cp' to create the release tag for Zope 2.8a2
> (whatever it is being called).
> 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:
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -