Just found a set_trace in ZODB/Connection.py
Is this intended ?
Good eye! It apparently was by someone during the recent ZODB sprint, but it certainly wasn't intended to persist beyond the branch it was used in. It's fixed now -- thanks for the report.
No. I also can't easily fix it in the Zope 3 tree because we are now using svn:external.
That's not "a fix", though -- would have left it broken in (at least) ZODB 3.4 branch, ZODB trunk, and in Zope2.
I would have fixed it in the trunk too. I wouldn't have thought of the 3.4 branch.
I need to find out the process that Tim wants to follow.
Same as changes to any other project you don't normally work on: submit a bug/patch to the collector, and/or raise a stink about it on
that project's mailing list. IOW, if you don't know how to fix a
thing, don't guess -- report it to someone who does.
Oh come on. Do you really want to be the only one who checks in ZODB fixes?
If some project has serious breakage it will often be unacceptable to wait for a fix.
I guess I need to:
- Fix it in the ZODB trunk
That's step 2 now. The first step was fixing ZODB 3.4 branch. Then merge the fix to ZODB trunk (because ZODB 3.4a1 was released, the ZODB trunk is for 3.5 develpment now). Then check that ZODB 3.3 branch and ZODB3 Zope-2_7-branch don't also have the problem. (And I already did all that stuff -- there's nothing left to do here.)
- make a new tag
- change the Zope 3 svn:externals to point to the new tag.
In this case, I didn't do either of those, because Zope3 is already using a unique-to-Zope3 tag (ZODB/tags/3.4.0a1-Zope3), to fix a unique-to-Zope3 problem with a ZODB test (obscure dependence in a hand-coded pickle on ZODB's Persistence, which latter Zope3 doesn't include).
So instead I merged this change to that tag.
which breaks tag rules. Now that tag is really a branch.
> Instead I could have
deleted the tag, then recreated it from 3.4 branch again; I had a weak reason to prefer the former in this specific case.
I think I'll wait to see what Tim thinks. This is not urgent because Zope 3 doesn't use this API.
OTOH, Zope 2 *does* use this API and the problem is there too.
Yes, the problem exists in ZODB/tags/3.4.0a1, and Zope 2.8a2 was already released using that tag.
"Between releases" I recommend pointing externals at the appropriate development branch, so that bugfixes to externals automatically show up in the clients that intend to use the next release on an external's development branch.
In the case of Zope2, that means I recommend redirecting its ZODB externals to ZODB/branches/3.4 for now (this is a dead-easy change -- two "svn propedit"s; "svn up"; run the tests; commit if successful, revert if not).
Then that means that a change tou make to the 3.4 branch could break Zope 2 unless you run the Zope 2 tests before the checkin.
Of course, if some project you don't know about follows the same strategy, you won't know to run their tests.
In the case of Zope3, I recommend leaving its ZODB externals pointing at ZODB/tags/3.4.0a1-Zope3 until an X3.1 branch is made from the Zope3 trunk.
What is the reasoning behind this recommedation?
In any case, I wouldn't have been able to predict what you wanted to do. So, I would have had to "follow the process" and submit a bug report. If I had significant breakage, I'd be in a bad spot.
-- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com