CVS, which stands for Concurrent Versions System, is a collection of programs which enable multuiple programmers to conveniently work on the same project. It makes aquiring the complete sources, checking changes in to the official version, summarizing changes, and version control easy and convenient.
CVS uses a client-server model. A CVS server has one or more respositories, which typically can be thought of as projects in Microsoft Visual C++ terminology, though this is not an exactly analogy. The CVS respository for each program is the master copy of that program. Individual programmers can retrieve as many copies of the respository as they like and work on them locally (in CVS terminology, you check out the respository). Once a programmer has finished making his changes, he sends his copy to the cvs server to become the current version of the repository. This is called checking it in.
The CVS server will handle when one programmer's changes conflict with another, and will also allow one to undo check-ins.
SolarTech's cvs respositories are hosted on Hepaestus (network name: devel-server.solartechnology.local).
This is probably described most easily with an example, so let's assume a very simple CVS setup. Let's say that we have two programmers, call them Nick and Chris, and one CVS respository, for The Program™.
Suppose that there is a bug in The Program™, and Nick and Chris are working together to fix the bug. To make sure that they're working from the production code, they each check out a fresh copy of The Program™. Through testing and reading the code, they discover that they're facing not one but two related bugs. Nick fixes the first, more complicated bug and Chris fixes the easier, less complicated bug.
At the moment, neither Nick nor Chris has a copy of the source for The Program™ which can be built and shipped to customers. This is where CVS saves the day. When Chris is finished with the fix for the smaller bug, he checks the fix into the CVS respository. Chris is prompted for an explanation of the change that he made, and the master copy is updated with the changes.
When Nick is finished with the update for the larger bug, he checks in his copy. Since Nick and Chris changed different portions of the code, there are no problems with the check in and Nick is prompted for an explanation of his change. (If there were conflicts that CVS could not automatically resolve, Nick would be prompted to resolve them manually.)
Now that the cvs repository has both bug fixes, Nick checks out a fresh copy of the CVS repository, builds The Program™ from scratch, and ships the compiled version off to the delighted customers.
First, you will need to download and install Cygwin, a suite of unix utilities for windows. You will want to select the following options:
Once cvs is installed, use the icon that it created to launch a shell. This shell gives you easy access to all of the programs that you just installed.
First, run the command:
and add the following lines (replace username with your username on Hephaestus):
EDITOR=nano
CVSROOT='username@devel-server:/var/lib/cvs'
export EDITOR CVSROOT
This will set the editor for commit messages to something reasonable. If you prefer a different editor (for example, vi) for whatever reason, change the EDITOR= line appropriately. The other thing it does is tell CVS where it can find the CVS repositories.
Once you're done doing this, log out of cygwin with the command:
When you next open a cygwin window, everything should be set up for you.
It will probably be easiest to create the directories to work in using Windows Explorer. Each time you want to check out a fresh copy of a repository, create a directory for it. When you are done with that copy, just delete the folder that you created it in. While this is a little more work, it does make using many versions quite easy.
The following instructions are all to be entered in the cygwin shell.
To go to a directory on your C drive, type:
If the directory that you want to go to does not have spaces in its name, you may omit the quotes.
To check out a repository, create a directory to hold it, cd to that directory, then use the command:
This will create a directory category with two subdirectories: CVS and progname. You may now go into category/progname and edit, build, etc. the program. When you wish to add your changes to the CVS repository run the following command in the directory category/progname:
If you know that someone else has committed a change that you want like in your local copy, run the following command in the directory category/progname:
There are a few other tidbits about using CVS which are good to know for practical use.
In order to facilitate files used locally for development but not meant to be included in a CVS repository (for example, compiled object files, test data files, etc), CVS must be explicitly told when a given file is to become part of a repository or to stop being part of it. The two relevant commands are add and remove (all of the following commands are done within the cvs checkout directory).
Remember that nothing that you do takes effect in the repository until you commit it, i.e. when you're done adding or removing files, run the command:
The repositories on hephaestus are organized in a shallow heirarchy. The following is an explanation of the heirarchy of respositories on Hephaestus, with the bold entries being the name to use with cvs commands:
This category is for all projects related to the Message Board
This category is for all of the software which runs on an arrowboard or is otherwise used to drive/use an arrowboard.
This category is for all software which is run on, or used to test, a display module.