RE: revision number less than 1.1

[Echlin, Michael]

Hi,

You have it wrong,
The source management system should also do release management, as in, give me all the files released in version x.x.x
CVS does this by you applying a release label to each of the files in a release. Of course CVS doesn't do this as well as other scm systems but you get what you pay for.

If you want advanced features, write them your-self or pay for ones that are tested.
This is not to say cvs isn't a good system, just that there are commercial ones out there that have more features, some of which can work with the same archive files thus giving you the opportunity to either move up to a more featured system if you need to or down to cvs if the system you tried to use is more then you needed.

I use a variety of SCM systems with different projects here. We are using cvs for some web pages and small one and two developer projects. We also have people still using rcs on unix projects, pvcs on a few projects, MKSSI on  some as well as qvcs and clearcase.

Different tools for different projects and different people. If I have a guy that has used cvs a lot and doesn't want to switch and he is comfortable with it, but there are a few new people on the same project, we can set it up so they all see the same archives with the scm tool of their choice if the situation warrants.

For release management I like to use MKSSI because of the fact I can verify a release 3 different ways. Date and time, labels and project checkpoint.

On cvs you have two ways, date and time, and labels. For most projects that is enough.
When you make a release with cvs, determine the version of each file that makes up the release. Write this down in a document for the release, a baseline release index, and then apply the same label to that revision of each file. Then check that each version has a date and time prior to the release. (if not you have marked a version as part of a release that happened before you checked in the file, not good.)

This will be a manual process but if you want good release management you have to do it.

Have fun,

Mike.

-----Original Message-----
From: address@hidden [mailto:address@hidden]
Sent: January 18, 2002 6:56 PM
To: Unlisted-recipients
Subject: Re: revision number less than 1.1

In article <address@hidden>,
Petr Aubrecht <address@hidden> wrote:
>The idea was to put $Revision$ into configuration file as a version number
>of the software. Then I have automatically increasing version number (like

This is a good idea if you want the user to be able to identify the
revision of each component (such as using ident or what commands).  But not
for identifying the version of the release.

>in Borland C++ Builder). It allows frequent releases and stay sure the user
>has the latest version. I don't like to do it manually (every day).

Borland C++ Builder is a build system.  Not an SCM system.

While it may be wise to keep track of the information in CVS, it should be
the build system (be it make or whatever) that assigns identification to
the release.

mrc

--
     Mike Castle      address@hidden      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs