[Zope-dev] Re: [Zope3-dev] Change in repository approach to software sharing

Chris Withers chris at simplistix.co.uk
Fri May 7 04:50:58 EDT 2004


Jim Fulton wrote:
>> 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:
>> http://svnbook.red-bean.com/svnbook/ch07s03.html
> 
> 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...)

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk




More information about the Zope-Dev mailing list