[.Tim Peters, a week ago Saturday, about Zope trunk under SVN]
> None of ZODB, ZConfig, or zdaemon are linked in any automated way to
> any version of Zope under SVN. Zope trunk ("2.8"), Zope3 trunk, and
> Zope X3 branch each have their own distinct copies of ZODB, ZConfig,
> and zdaemon. Checking in from one copy has no effect on any other
> copy. For that matter, the ZODB trunk and branch each have their own
> distinct copies of ZConfig and zdaemon too.
... [.and the ZODB copy in Zope trunk was at best 4 months old] ...
> I *expect* this will be easy to repair, if I can get bandwidth from
> Jim to clarify how he originally stitched ZODB into Zope trunk ...
I'm back from vacation, and think I'm nearing the end of this part.
If final tests pass, I'll check it in, probably within an hour. "It"
means stitching a current version of ZODB 3.3 into Zope trunk, plus
enough other changes so that the Zope tests all pass again.
That specifically means these 8 directories under Zope's lib/python/,
copied from the same-named directories under ZODB's src/ directory:
ZODB
ZEO
persistent
transaction
BTrees
ThreadedAsync
Persistence
ZopeUndo
and also Zope's utilities/ZODBTools/ directory, which is a renamed
copy of ZODB's src/scripts/ directory.
I have not looked at the state of ZConfig or zdaemon in Zope trunk,
and probably won't (I don't know much about them).
I also need to check in a number of changes to Zope trunk's tests, to
account for that:
1. Transaction.begin() is deprecated, and dangerous, in 3.3. The correct
spelling is now:
import transaction
transaction.begin()
It's "dangerous" for reasons explained in ZODB's NEWS file; in short, while
txn.begin()
still aborts the current transaction and starts a new one, it creates a new
transaction *object* too -- 'txn' is no longer the current transaction object
after 'txn.begin()'. That's deadly in the (very) few cases where people go
on to use 'txn'. Much more common is the spelling:
get_transaction().begin()
and that's harmless (although it's still deprecated, and will go away ASAP
after 3.3).
2. Failure of a transaction to commit is "sticky" in 3.3 now -- all subsequent
attempts to commit will continue to fail, until the transaction is explicitly
aborted, or transaction.begin() is called. Curiously, the problem I've had
with that so far is in the newer Transience tests. UncommittableJar had
to grow a new do-nothing abort() method (so that the transaction it's
involved with *can* be explicitly aborted), and TestTransactionHelper.
testUncommittable() had to add "transaction.abort()" at the end, else
the commit failure that test provoked prevented future tests from doing
a commit too.
So I think ZODB 3.3 in Zope trunk will be in good shape again starting
tonight. I don't know about ZConfig, zdaemon, or the spurt of
non-ZODB bugfixes that went into (what will soon be) Zope 2.7.3.
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders