[Zope-dev] Re: [Zope3-dev] Change in repository approach to software sharing
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Change in repository approach to software sharing
Jim Fulton wrote: We'll also have a top-level ZConfig project directory. The trunk of the ZConfig Python package will be in ZConfig/trunk/src/ZConfig. If we create a tag T1 of ZConfig, then the Python package for that tag will be in ZConfig/tags/T1/src/ZConfig. The /src/ in the above paths seems like a dead chicken to me, why's it there? Now, when we set up the Zope 3 repository, we will create the ZConfig package in Zope 3 by copying a *tag* from the ZConfig project: svn copy svn+ssh://svn.zope.org/repos/ZConfig/tags/T1/src/ZConfig \ svn+ssh://svn.zope.org/repos/Zope3/trunk/src/ZConfig -m 'Bring ZConfig T1 into main branch' I think you'll find this doesn't work when svn+ssh://svn.zope.org/repos/Zope3/trunk/src/ZConfig already exists. It's the one thing that's disappointed me about SVN so far :-( (well, that and not beign able t odo inter-repository operations ;-) Later, we may decide to upgrade the Zope 3 head to use ZConfig tag 3. At that point, we can recopy from the tag, or we can merge changes made between the two tags. 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. Merges in SVN have ended up feeling a LOT nicer for me that with CVS, but the key is still to keep the number of maintained locations of a piece of shared software to an absolute minimum, as Tim points out. 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 The svn:externals way of doing things means you only develop the shared software it it's own tag/trunk/branches structure and just link to it from where you want to use it, which sounds like it might save a few grey hairs on Tim's part since there won't be any local development in the locations where the shared software is used... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Change in repository approach to software sharing
Chris Withers wrote: Jim Fulton wrote: ... Now, when we set up the Zope 3 repository, we will create the ZConfig package in Zope 3 by copying a *tag* from the ZConfig project: svn copy svn+ssh://svn.zope.org/repos/ZConfig/tags/T1/src/ZConfig \ svn+ssh://svn.zope.org/repos/Zope3/trunk/src/ZConfig -m 'Bring ZConfig T1 into main branch' 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. Later, we may decide to upgrade the Zope 3 head to use ZConfig tag 3. At that point, we can recopy from the tag, Do do so, we may have to remove the old copy first. or we can merge changes made between the two tags. 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. Merges in SVN have ended up feeling a LOT nicer for me that with CVS, but the key is still to keep the number of maintained locations of a piece of shared software to an absolute minimum, as Tim points out. There should be only one place that shared software is maintained. Periodically, we'll need to resync copies. 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 - A use of the software can make what they might think is a local change, check it in, and break other users. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
