[cvsnt] Forced revision problems

Tim Chippington Derrick tim at chippingtonderrick.co.uk
Thu Jun 15 15:14:42 BST 2006

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.


This is a common mistake and one that I got caught up in when I first 
started with CVS. The key point is to remember that the file revision 
numbers are *purely* there for us and CVS to distinguish different 
versions of each file. In a typical module/project you may have many 
different files, and it would be almost impossible to get all the 
revision numbers on all the files to sensibly line up for each new 
version of the module. So we all use tags instead. In a typical 
process you will probably be editing a number of files together until 
you are happy with their state and decide to make that set of 
revisions of those files into a particular "release" version. At that 
point, when they have all been committed back to your CVS server, you 
then "tag" all those files (or better tag the whole module) with some 
identifiable name. We use names here like "V_1_2_3". The tag is just 
a convenient symbolic label - you could do the same by just recording 
the date on which the release was "frozen" and later you could check 
out the module again as it was on that date. But a tag is much 
easier. It's useful to devise a naming strategy for the tags too, so 
you can distinguish between e.g. test builds and releases.

Forcing revisions on a file is, with hindsight, not the sort of thing 
that you really want to do. Change the way you think a bit, and don't 
get hung up on the individual file version numbers. Most people now 
using CVSNT probably hardly ever look at the individual file revision 
numbers. We do record the file version numbers used for each release 
- its normal good practice to record a build specification that 
includes this information; but that just gets filed as part of the 
usual audit trail stuff that nobody ever looks at unless things go 
wrong. Now we just let CVSNT do its own thing with the individual 
file version numbers and we concentrate on getting the file contents 
right and then tagging the whole module at key points like releases.

Hence, the option for forcing a revision was deemed to be practically 
useless and potentially dangerous; so I believe it was removed quite 
a long time ago from CVSNT.

Basically, unless you are doing something *very* specific, don't 
bother. It won't work with CVSNT anyway

At 14:34 15/06/2006, you wrote:
>I am having an issue forcing revisions with cvsnt 2.5.03.  I was able to
>force revison on a linux cvs server, but now that I have moved to cvsnt I
>get two errors when attempting to force revisions.  The command text and
>errors are:
>cvs commit -m "no message" -r 2.0 filename
>cvs server: nothing known about `2.0'
>cvs server: nothing known about `--'
>I am using wincvs as a front end and have attempted both the standard
>checkbox for forcing revisions and using the command line with the above
>command and get the same error.  If anyone knows how to get the forced
>revisions working I'd appreciate the information.
>cvsnt mailing list
>cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
>http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs

More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook