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.
Hi 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