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

[Kapil Thangavelu]

On Fri, 2004-10-15 at 13:03 +0000, Dmitry Vasiliev wrote:
> 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". :-)

we use svn:externals a bit for archetypes and plone. it works pretty
well for us. for stitching things together into bundles that can be
checked out to get all the deps from the proper branches. its a whole
lots less error prone imho the making lots of copies and trying to merge
stuff around, getting into a scenario with multiple origins for changes
and merging back and forth isn't fun. though, there's a cool tool if
your doing this sort thing on linux called meld (gtk-python), although
i'm sure emacs die hards would prefer ediff ;-)

cheers,

-kapil