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

[Dmitry Vasiliev]

Tim Peters wrote:
> [Dmitry Vasiliev]
> ...
> 
>>'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.

Yes, Subversion documentation list all this gotchas:

     http://svnbook.red-bean.com/svnbook-1.0/ch07s03.html

But there is one more problem: need to hardcode repository access scheme 
in 'svn:externals', e.g. if you define 'svn:externals' for svn+ssh:// 
scheme you then won't access the externals through http:// scheme 
without ssh authorization.

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

Now then I look closer on 'svn:externals' I think "the technology is 
still very young". :-)

-- 
Dmitry Vasiliev (dima at hlabs.spb.ru)
     http://hlabs.spb.ru