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:
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 Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce