[Zope3-dev] set_trace in ZODB

[Tim Peters]

[jürgen Kartnaller]
>> 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.

[Jim Fulton]
> 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 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.

> 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.  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).

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.

It would be very good to do something sane with externals for zdaemon
and ZConfig too.  As is, I doubt that any two of {Zope3, Zope2, ZODB}
development use the same versions of either.