[ZODB-Dev] zope.interface, zope.testing

[Tim Peters]

[Dmitry Vasiliev]
>>> What the best way to update ZODB/src/zope packages?

[Tim Peters]
>> Benign neglect has worked well so far <wink>.

[Dmitry Vasiliev]
> Not so well... :-) Try 'python test.py -B' for example.

Does using current Zope3 trunk src/zope/{interface,testing} pieces repair
that?  I don't know.  Jeremy traditionally had no use for in-place builds,
so I never expect test.py to work with an in-place ZODB build -- the idea
that I might even try it was beaten out of me long ago.

...

>> Note that the ZODB trunk is for ZODB 3.4 development at this point.
>> Bugfix releases for 3.3 (3.3.1, 3.3.2, ...) will be developed on the 3.3
>> branch (repos/main/ZODB/branches/3.3).  Like all the other "module
>> stitching" under SVN, the copies of src/zope pieces under ZODB trunk and
>> branch are independent.  This is easy to see today, because the ZODB 3.3
>> branch doesn't have any src/zope pieces.

> So should I update ZODB/zope only on the trunk?

ZODB/src/zope only exists on the ZODB trunk, so that's the only ZODB place
it could be updated.

As above, if your goal is to make "test.py -B" work, make sure (via local
"svn switch"s first) that such updating actually helps.  I doubt that it
will (for example, ZODB trunk's test.py looks nothing like Zope3 trunk's
test.py anymore).

Note that the ZODB 3.3 branch needs to work with Zope 2 too, and the
src/zope/ pieces you're talking about were copied out of Zope3.  I don't
want to introduce Zope3 dependencies in a project targeting Zope2, at least
not before Zope2 is willing to bite that bullet too.

Note also that, even on the ZODB trunk, Zope3's src/zope/testing was copied
in only because Zope3's src/zope/interface depends on it (see the checkin
comment for rev 25940; there was no intent to convert ZODB trunk to use
Zope3's testing machinery; that's not necessarily a bad thing to do, but it
was at best an irrelevant consideration at the time).

> BTW, why just not use 'svn:externals'?

For what, specifically?  Jim got it into his head <wink> that making endless
copies of everything all over the place under SVN was "a good idea".  I
don't know whether it is for him, but I've gotten nothing but pain from it.
I liked the module sharing we did under CVS much better.  svn:externals
doesn't appear to be equivalent to that, though, so I have no experience
with svn:externals, nor with anything else quite like it.