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

[Tim Peters]

[Dmitry Vasiliev]
...
> Is interfaces in ZODB only for documentation purposes for now?

Yup, that's the current purpose, although imports of interface files also
create real dependencies.  Part of the plan is that all ZODB classes will
grow matching interfaces, for a combination of documentation and sanity
purposes.  Adaptation machinery building on interfaces will also appear.
For example, 3.3 _transaction.py's internal MultiObjectResourceAdapter and
DataManagerAdapter classes are effectively building adaptation by hand now.
This is obscured because they can't yet name the interfaces they're trying
to adapt.

...
> 'svn:externals' is like a soft links in Unixes I think, but I have no
> experience with it too.

Googling suggests some gotchas with externals, where directory A "externals
in" a foreign directory E:

- While changes checked in to pieces of E from its natural home show up
  in A, changes to pieces of E made *in* A don't propagate back to E's
  natural home via svn commit made from A.  IOW, "svn commit" doesn't
  recurse into A's externals.  Someone working in A has to explicitly
  cd to each external'ed directory and svn commit from there.

It's hard to guess whether that's better or worse than copying.  I think
there are only two people now who know *how*, e.g., ZODB gets stitched into
Zope, Zope3, or ZopeX3; or zdaemon or ZConfig either, for that matter.  Most
people have no idea, so check in changes from wrong checkouts.  It's very
easy to lose such changes now (because it takes real effort not to, and
because the only absolute *need* to is during a release crunch, the worst
possible time to throw indefinitely delayed "guess and merge" tasks into the
mix).  Using externals, I guess at least svn status would continue to remind
them that their changes to externals are still unique to their personal
checkout (until they explicitly cd to A's E and check in their changes from
there).

- If the svn:externals entry for E doesn't hardcode a specific revision
  number, then when A is copied (branched or tagged), the copy continues
  to see changes made to E.

IOW, you don't get a snapshot of E when you make a snapshot of A.  If A
originally referred to, e.g., external svn.zope.org/repos/main/ZODB/trunk,
then copies of A also refer to ZODB trunk, not to the revision of ZODB trunk
current at the time the copy was made.

For things like release tags, that would be a disaster.  Whoever made such a
tag would have to be acutely aware of how all externals got stitched in, and
change them in the tag to hardcode appropriate revision numbers, or replace
the externals in release tags with copies.

But in all, still sounds less error-prone than what we do now.