Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
"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