[cvsnt] Re: Increasing release with "commit -r" fails

[Axel Eckenberger]

"Tony Hoyle" wrote in message news:cfeb05$upn$2 at paris.nodomain.org...

> > C:\temp\test\DataProv\MDirProv2>cvs commit -m "none" -r 2.0
AssemblyInfo.cs
> > Checking in AssemblyInfo.cs;
> > cvs [commit aborted]: revision `2.0' does not exist
>
> You can't do this.  2.0 is a 'reserved' number by RCS and you can't
> create a revision with that number anyway, plus you can't use commit -r
> to create it (import will create 2.x.x branches if it has to).

This contradicts the information available on the net, where nearly all
sources (Cederquist, cvsnt wiki) name this method for increasing the release
number part of the revision number (i.e. from 1.x to 2.x). If the -r switch
is not used for this, what is it good for? Also the comments in commit.c
also indicate that increasing the release number is what it is for. So
either the functionality is obsolete, it is not described properly, there is
something wrong with it, or I'm not using it correctly.

> Don't use -r to specify revisions.  Revision numbers are internal to CVS
> and shouldn't changed.  Use tags to mark specific revisions instead.

Generally this is correct, however the release number, i.e. the first number
in the revision number is not AFAI found out not connected to the revision
number itself, at least that's what the doc says. Otherways a simple counter
would do for the most cases - except branching.

The reason behind this question ist that other versioning systems I've been
working on do not have this mechanism. In certain cases it migt be appealing
to bring the source up to a common revision number to show that there is a
logical break between the versions, which goes beyond the meaning of a tag.

TIA

Axel