Managing CVS

[Robert Brenstein]

>On 24/4/07 12:44 AM, "Robert Brenstein" <rjb at robelko.com> wrote:
>
>>>>  And yes, being able to release 2.5.10 after 3.0 should be not just
>>>>   possible but easy if you do things right :-)
>>>
>>>  Yes, "as easy" as above steps, Robert.
>>
>>  Well, let's agree that we disagree. If you fix problems in the head,
>>  then yes, indeed fixing earlier branches is a headache. Fixing should
>>  be done in the oldest active branch, so CVS tools can be used to
>>  merge them up into the newer branches and the head. That works
>>  simpler.
>
>I wonder, does your project team have some instructions how to manage CVS in
>that project? If yes, will be happy to read exact steps.

http://docs.moodle.org/en/CVS_%28developer%29

This is not so evident from those short instructions, but many 
modules in this project have their own versioning besides branches 
matching the branches of the core product.

Some locations which do heavily development in this project, 
particularly if they develop local extensions, have their own 
repositories using GIT which they sync up (vendor branch) and down 
(local branch). I mention that only because they consider GIT to be 
superior for more complex projects.

http://en.wikipedia.org/wiki/Git_%28software%29


>We have try already few ways actually:
>     e.g. 2.5 was main branch, and 3.0 was separate secondary.
>
>now we have change this
>     3.0 is in head, and e.g. 2.5.10 we can make as I did describe
>     following to what I have read about "how to make bug-fix build"
>articles.
>

The main trunk, or the development head, should always be the newest 
code, so your new setup is surely more proper. Actually, in my 
experience, the trunk has no formal version until it is actually 
branched even if you refer to it as version 3.0, for example. 
However, you should not have to "make" the earlier branches as you 
describe. There is something wrong with that approach.

Robert