Providing customized source code control with CVS
Providing customized source code control with CVS
Once CVS is installed, and a repository available, it is ready to use. There is a limited set of commands and options that suffice to get started.
It will be necessary to check out a module to work in. CVS uses the phrase "check out" differently from many similar systems. In CVS, a "check out" means that you get a copy of the module in your local directory, all set up to run CVS commands. It gives no special permission to check in changes, although in CVS as originally used everybody had such permission.
It will be necessary to keep the local copy up to date. This is done with the "cvs update" command, which will produce a report listing new files, changed files, and locally modified files. If there are files that are locally modified and also changed in the repository, CVS will try to merge the changes, and the report will list that.
The "cvs update" command is also excellent for getting a general view of how the local directory differs from the repository, since it can be run without doing any actual updating, just to produce the report.
CVS provides a facility to let people know who is working on which file or files, and the development process may use this. Users may be required to file a notification that they will change a file before doing so, and may be asked to check first if anybody else is changing the file.
There are commands to add and delete files. Remember that all addition, deletion, and changing of files is done only locally until these changes are checked in. Directories work somewhat differently: you cannot delete a directory (instead, delete all the files in it), and if you locally add a directory it is added in the repository. If you've added a directory by mistake, talk to the CVS administrator.
Once all the work is done, and all prerequisites to checkin satisfied, the changes may be checked in or committed. CVS requires that all files be up to date in order to be checked in, so if any have changed in the repository it will be necessary to update the local directory to merge in the changes. CVS will ask you to provide a log comment for each checkin.
CVS will produce a file listing, annotating each line with columns of when it was last changed, by whom, and the revision number of the change. This is very useful when trying to find out when changes were introduced.
CVS has a status command, which will show assorted status information on specified files, and a log command, which will produce a potentially long listing giving the checkin comments, dates, and tags.
CVS can provide you with listings of the differences between your local copy of a file and the repository copy, or of any two revisions inside the repository.
There are two sorts of tags in CVS: branch tags, which are continuing lines of development, and revision tags, which mark points in the development of the repository. They are used very differently, and are treated similarly for historical reasons.
All contents of these pages Copyright 2002 by David H. Thornley.
Permission granted for verbatim copying and use within an organization.