[Zope-dev] RE: Re: svn vs. cvs (some documentation)

[Tres Seaver]

Jim Fulton wrote:
> Tres Seaver wrote:
> 
>> Jim Fulton wrote:
>>
>>>> 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:
>>
>>
>>
>> The complaint you made earlier today (about bugs fixed on the head, 
>> but not on the release branch) is a symptom of this issue.  FWIW, it 
>> is standard doctrine that bugs should be fixed *first* on the release 
>> branch, and then forward-ported to the trunk, rather than vice versa.
> 
> 
> I agree that that is a good doctrine.
> 
> ...
> 
>> When collaborating on a feature which touches many files, it is often 
>> desirable to check in intermediate versions;  activity branches make 
>> this possible, without risking the stability of the trunk. 
> 
> 
> Yup.  There are definately examples of this in Zope 3's history
> and future.  I'd put it a little differently, in that it is
> not necessarily the number of files but the overall time to
> complete a development project that sometimes makes separate development
> (activity) branches necessary.
> 
>  > The CVS
> 
>> document (http://dev.zope.org/CVS/ZopeCVSFAQ) says:
>>
>>    It is very important that the trunk remain stable so that releases
>>    can be made on short notice. To keep the trunk from becoming
>>    unstable, all work is done on branches in CVS and when the work has
>>    stabilized it can be merged into the trunk.
> 
> 
> For Zope 3 and svn, I would change this to something like:
> 
>     It is very important that the trunk remain stable so that releases
>     can be made on short notice. To keep the trunk from becoming
>     unstable, no change can be checked into the trunk, or to a
>     release branch unless:
> 
>     - All tests pass, and
> 
>     - All new code has adequate unit and functional tests.
> 
>     If you need to check in intermediate work, because a project
>     takes a long time or there are multiple participants, then
>     create a development branch and work there.  When development is
>     completed and the resulting changes are stable and adequately tested,
>     then the branch can be merged to the trunk (or to a release branch)
>     and committed if all tests pass.

OK, that sounds fine.  Another reason for an activity branch:  the work 
is "experimental", and may never be merged;  putting on a branch lets 
others evaluate it without risking stability.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com