RE: [Zope3-dev] Re: svn vs. cvs (some documentation)
http://dev.zope.org/CVS/ContributorFAQ refers to CVS (and zope3-dev). I think all references to CVS should be changed to SVN. Should I go ahead and update the document?
No. CVS is still used for managing the 2.7 branch of Zope, and is still relevant there.
Tres.
Speaking of, the dev.zope.org/CVS/ area should probably be updated to: 1. capture the current state of affairs (2.8 / HEAD on svn and 2.7 on CVS), since it is currently mostly 'in the heads' of the various Zope devs 2. translate the CVS FAQ to the svn world (recommendations for how to manage our 'activity branch' pattern in svn in particular 3. clarify other questions that would be obvious to new devs looking at that area of the site for guidance ;) I've bcc'ed to myself to try to make a stab at this as I can, but its pretty likely someone out there could get this done faster. If you can get the me the content, I promise I can get your mods up on the site quickly ;) To the zope-web folks and others managing zope.org content - we should also change the 'Zope CVS' (and zope.org/CVS) to 'Contributing' or some such... Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Brian Lloyd wrote: ...
Speaking of, the dev.zope.org/CVS/ area should probably be updated to:
1. capture the current state of affairs (2.8 / HEAD on svn and 2.7 on CVS), since it is currently mostly 'in the heads' of the various Zope devs
Good point.
2. translate the CVS FAQ to the svn world (recommendations for how to manage our 'activity branch' pattern in svn in particular
Note that this is somewhat dependent on the Zope version. In Zope 3, we make much less use of development branches because: 1. We prefer increments of change to be small. (This might be a useful goal for Zope 2 as well.) 2. We have far more tests: a. New code is required to have it's own tests b. Tests must always pass on the trunk or on release branches.
3. clarify other questions that would be obvious to new devs looking at that area of the site for guidance ;)
:) Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Brian Lloyd wrote:
...
Speaking of, the dev.zope.org/CVS/ area should probably be updated to:
1. capture the current state of affairs (2.8 / HEAD on svn and 2.7 on CVS), since it is currently mostly 'in the heads' of the various Zope devs
Good point.
2. translate the CVS FAQ to the svn world (recommendations for how to manage our 'activity branch' pattern in svn in particular
Note that this is somewhat dependent on the Zope version.
In Zope 3, we make much less use of development branches because:
1. We prefer increments of change to be small. (This might be a useful goal for Zope 2 as well.)
2. We have far more tests:
a. New code is required to have it's own tests
b. Tests must always pass on the trunk or on release branches.
And, 3. Up to this point, we haven't had to be careful about managing bugfixes across multiple releases. We also haven't had lots of "independent" feature work going on in the core. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Tres Seaver wrote:
Jim Fulton wrote:
Brian Lloyd wrote:
...
Speaking of, the dev.zope.org/CVS/ area should probably be updated to:
1. capture the current state of affairs (2.8 / HEAD on svn and 2.7 on CVS), since it is currently mostly 'in the heads' of the various Zope devs
Good point.
2. translate the CVS FAQ to the svn world (recommendations for how to manage our 'activity branch' pattern in svn in particular
Note that this is somewhat dependent on the Zope version.
In Zope 3, we make much less use of development branches because:
1. We prefer increments of change to be small. (This might be a useful goal for Zope 2 as well.)
2. We have far more tests:
a. New code is required to have it's own tests
b. Tests must always pass on the trunk or on release branches.
And,
3. Up to this point, we haven't had to be careful about managing bugfixes across multiple releases.
Sure we have. We've had a release branch for some time. Perhaps I should add: 4. Subversion makes it much easier to manage and merge changes, since repository-wide revision numbers provide the same capabilities as tags and, thus, make tagging mostly unnecessary.
We also haven't had lots of "independent" feature work going on in the core.
Not sure what you mean by this. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (3)
-
Brian Lloyd -
Jim Fulton -
Tres Seaver