When you make a major release of your product, you might want the revision numbers to track your major release number. You should normally not care about the revision numbers, but this is a thing that many people want to do, and it can be done without doing any harm.
To bring all your files up to the RCS revision 3.0 (including those that haven't changed), you might do:
$ cvs commit -r 3.0
Note that it is generally a bad idea to try to make the
RCS revision number equal to the current release number
of your product. You should think of the revision
number as an internal number that the CVS package
maintains, and that you generally never need to care
much about. Using the tag and rtag
commands you can give symbolic names to the releases
instead. See section tag--Add a symbolic tag to checked out versions of files and See section rtag--Add a symbolic tag to a module.
Note that the number you specify with `-r' must be larger than any existing revision number. That is, if revision 3.0 exists, you cannot `cvs commit -r 1.3'.
You can commit to a branch revision (one that has an
even number of dots) with the `-r' option. To
create a branch revision, use the `-b' option
of the rtag or tag commands (see section tag--Add a symbolic tag to checked out versions of files
or see section rtag--Add a symbolic tag to a module). Then, either checkout or
update can be used to base your sources on the
newly created branch. From that point on, all
commit changes made within these working sources
will be automatically added to a branch revision,
thereby not disturbing main-line development in any
way. For example, if you had to create a patch to the
1.2 version of the product, even though the 2.0 version
is already under development, you might do:
$ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module $ cvs checkout -r FCS1_2_Patch product_module $ cd product_module [[ hack away ]] $ cvs commit
This works automatically since the `-r' option is sticky.
Say you have been working on some extremely experimental software, based on whatever revision you happened to checkout last week. If others in your group would like to work on this software with you, but without disturbing main-line development, you could commit your change to a new branch. Others can then checkout your experimental stuff and utilize the full benefit of CVS conflict resolution. The scenario might look like:
[[ hacked sources are present ]] $ cvs tag -b EXPR1 $ cvs update -r EXPR1 $ cvs commit
The update command will make the `-r
EXPR1' option sticky on all files. Note that your
changes to the files will never be removed by the
update command. The commit will
automatically commit to the correct branch, because the
`-r' is sticky. You could also do like this:
[[ hacked sources are present ]] $ cvs tag -b EXPR1 $ cvs commit -r EXPR1
but then, only those files that were changed by you will have the `-r EXPR1' sticky flag. If you hack away, and commit without specifying the `-r EXPR1' flag, some files may accidentally end up on the main trunk.
To work with you on the experimental change, others would simply do
$ cvs checkout -r EXPR1 whatever_module
Go to the first, previous, next, last section, table of contents.