[Zope-dev] Clarification re: Zope X3.1, 2.8

[Tim Peters]

Zope trunk is using ZODB 3.4 now.  It's been switched to use
svn:externals to stitch in the 9 ZODB directories.  For now they're
pointing at ZODB trunk.  A release tag will be made later (this is
_not_ ready for release yet; now I can start doing the work I wanted
to start doing on Monday <0.5 wink>).

The Zope3 code is now gotten from new tag
Zope3/tags/ZopeX3-3.0.0-Zope-2.8-a2.  That code was purged of
get_transaction() calls, and the IDataManager glitch got repaired
there.  If that code needs more changes, they should be made on
Zope3/branches/ZopeX3-3.0.0-Zope-2.8, another tag made from the
result, and the lib/python properties changed to point to that tag.

Really helpful:  you can do "svn propedit" followed by "svn up" to
_temporarily_ redirect your local copy to a different source for
svn:externals.  If you "svn revert" the propedit changes before a
commit, nobody else will be affected.

A handful of get_transaction() calls were also removed from the Five code.

Zope's setup.py got taught how to build ZODB 3.4's new IFBTrees.

All tests should pass on Linux (the same two still fail on Windows). 
There should be no DeprecationWarnings related to transactions.

I'm not sure svn will do a decent job of updating.  We're
simultaneously trying to delete Zope trunk's *copies* of ZODB code,
and stitch the same things (well, directories of the same names) back
in via svn:externals.

At one point during the Zope/branches/tim-merge-zodb34 merge on my
local box, svn got itself terminally confused, starting to create
directories like lib/lib/python/ZODB (there are two "lib/"s in that --
not a typo), and griping endlessly about locks and non-existent files.
 No amount of "svn cleanup" could repair it, and I ended up checking
out Zope trunk from scratch again.  Then all the problems went away.

If people have trouble updating on Linux, say so here, and we can
share solutions.  I hope that I hit problems just because I was doing
the merge.