The structure of each CVS command, entered from the command line is:
To get help use the -H flag with CVS or with a particular command:
Note that revisions are immutable, so they can never be changed and re-commited. Only the main trunk and branches can be commited back later. The -r flag refers to a tagged version which you are checking out. For each file in the repository you will get the RCS version of that file which matches that tag rather than the "head", or latest version. Thus a tag defines a cross-section of RCS file revisions. (Note: RCS is the file-by-file version control system that CVS is built upon).
To update your copy of a module with any changes from the central repository execute:
This will tell you which files have been updated (their names are displayed with a U before them), and which have been modified by you and not yet committed (preceded by an M).Here is a full list of update outputs from reference manual.
It can be that when you do an update, the changes in the central copy clash with changes you have made in your own copy. You will be warned of any files that contain clashes by a preceding C. Inside the files the clashes will be marked in the file surrounded by lines of the form <<<< and >>>>. You have to resolve the clashes in your copy by hand. After an update where there have been clashes, your original version of the file is saved as `.#file.version'.
If you feel you have messed up a file and wish to have CVS forget about your changes and go back to the version from the repository, delete the file and do an cvs update. CVS will announce that the file has been "lost" and will give you a fresh copy.
To display all files which are not up-to-date without actually changing anything in your working directory:
You can use the -r flag with cvs update as well, with the following possibilities:
If your local version is up-to-date with respect to your base version (as determined by your sticky tag), i.e. there are no file that need to be commited since your last checkout or update, update -r simply change your local version to reflect the repository, as-if you had checked-out that version from scratch. However, if you have changes, then update merges the differences between your changes and the base version with the -r version files into your local repository (see the manual if my explanation is unclear here!).
When you do a commit, if you haven't updated to the most recent version of the files, CVS tells you this. You will have to first update, resolve any possible clashes, and then redo the commit.
You should not commit changes until they are ready for consumption by other developers. At minimum you should compile you changes and verify that at least a minimum level of tests (say, the acid tests) pass.
NOTE: Take your time here. CVS will inform you of files that may have changed or it does not know about (watch for the ? lines) and then with ask you to confirm this action. Make sure you want to do this.
NOTE: With the way we are using CVS, releasing is not strictly necessary. rm -r (or deletion via File Manager) is okay if you are sure you have successfully commited your changes.
Use cvs tag to tag the version of the files that you have checked out. You can then at a later date retrieve this version of the files with the tag.
Later, you can do:
A tag can be deleted with the -d option:
Generally, deleting tags may not be a good idea. Definitely do not delete a branch tag. Of course benchmark versions (i.e. v02) should never be deleted once they have been tagged correctly. Unless developers find them personally useful, we should probably stay away from using a bunch of random tags, and then stick to rtag for release management.
See that manual about vendor branches, for playing with a demo the names are not important. The above command will create a module named demo and import into it all the files and directories in the current directory.