Re: How to proceed ?

[Mark D. Baushke]

Gyetvan Andras <address@hidden> writes:

> It is not exactly a CVS issue, but... So our team will release the
> project's first version (1.1) soon. We will continue to develop to add
> 1.2 functionality to the code. The 1.1 version will be put in field,
> so we expect a few modification in 1.1 (small bugfixes, minor
> modifications). With CVS I can do a branch for 1.1 source and maintain
> the merging between 1.1 and 1.2 (if needed).

Seems reasonable.
 
> My questions are the following :
> 
> - what is the best practice to do this ?

I would suggest that you create a version tag for the 1.1 release. If at
a later time, you need to bugfix it, you may create a branch from that
point and commit your point bugfix to the branch and eventually release
a 1.1.1 release of your software. Obviously, you will need to commit the
same bugfix to the main trunk which is your work in progress toward
version 1.2.

> Create a new module to 1.2 and maintain the code merging manually
> between versions ? 

No. If the code has the same basic structure, you wan to use the same
module. Take a look at how the ccvs module is handled on cvs.cvshome.org
for an example.

> Create a branch for 1.1 (or 1.2) to maintain the same.

Yes.

> - if I decide to create a new module for 1.2 instead of a branch, is
> there a possibility to diff, merge between modules ?

Nope. You would be left with the standard use of 'diff' and 'patch'
as if they were not really related software.
 
> - is there a way to specify automatically the name of the directory
> where CVS will checkout the source ? I mean, if I have a module in the
> repository named "app.code". This module has a branch called
> "rev-1-1". It vould be fine when I checkout the "rev-1-1" branch, then
> CVS put the source into a directory called "app.code.rev-1-1" (or
> something different than "app.code") instead of "app.code".

cvs checkout -d app.code.rev-1-1 -r rev-1-1 app.code

        Enjoy!
        -- Mark