I think you'll find this doesn't work when svn+ssh://svn.zope.org/repos/Zope3/trunk/src/ZConfig already exists.
That's not relevent to the example, as, in the example, we are creating it for the first time.
Yep, I know, but I've been there, and you feel great after the first time ,and disappointed when it doesn't work again ;-)
Do do so, we may have to remove the old copy first.
Yeah, which means two operations for each copy :-S
My experience has been that it's best just to have shared software "exist" in each location where it's used and maintained in those places with new versions being brought across via merges.
That's what I'm suggesting.
...hence just doing the merge which is the desired effect anyway ;-)
Another option, and one which I'd really strongly suggest here if it could be made to work is the "external definitions" stuff:
That's close to what we have now, with repolinks. It's cleaner that repolinks,
but it has the same basic flaw, the shared software is *truly* shared:
- Users of the software have no control over when they get changes to it
I may have misread the external definitions docs, but I'm pretty sure you specify a revision number in the property, so you only ever get the exact version you want, and hence changes when you want them. Or did I miss something?
- A use of the software can make what they might think is a local change, check it in, and break other users.
Indeed. But since "other users" will stick with their specific revision, this should be okay, and it's better that such breakages get found sooner, rather than having several gradually forking copies of the same code (I almost ran into this problem with some custom products used in multiple SVN'ed instance-home's before slapping myself very hard...)
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce