Source Revision Control Tutorial


What is CVS?

CVS is an acronym for the "Concurrent Versions System". CVS is a "Source Control" or "Revision Control" tool designed to keep track of source changes made by groups of developers working on the same files, allowing them to stay in sync with each other as each individual chooses. CVS is free and runs on many computers and operating systems -- such as WindowsNT, Win95, Mac, etc. To install and build CVS, your computer must have a C-compiler, RCS, and PERL accessable from your computer (at least this is what is required for UNIX platforms). It is also available for the Windows NT operating system (although no NT clients I know of have the software installed).

There is also a GUI front end available that can be downloaded for free.  It requires that TK and TCL has also been installed in an directory that is accessable by your computer. MVS has a nice tool called tkdiff, to view differences between various revisions of files. This will be presented in  tutorial #3 .


What does CVS do?

CVS is used to keep track of collections of files in a shared directory called "The Repository". Each collection of files can be given a "module" name, which is used to "checkout" that collection.

After checkout, files can be modified (using your favorite editor), "committed" back into the Repository and compared against earlier revisions. Collections of files can be "tagged" with a symbolic name for later retrieval.

You can add new files, remove files you no longer want, ask for information about sets of files in three different ways, produce patch "diffs" from a base revision and merge the committed changes of other developers into your working files.

illustration of cvs revision tree

New revisions are commited back to the repository and given a new number. The revision-tree figure above shows how CVS will let you 'branch' from the main 'trunk' and work with sub-revisions.  These sub-revisions can then be merged back into the main trunk.  You can even 'tag' files having different revision numbers into a common revision name.  The tutorials will NOT go through examples how to do this.

And, most importantly, you can go back to an older version that you know worked before you added 'new features' -- eg, bugs!

Just for your own information, this tutorial is managed by CVS. ;-)


What does CVS NOT do ?

CVS does not employ a 'lock' mechanism on 'files-in-use'. Imagine if I checked out a file, and left for vacation for 2 weeks. If the file was 'locked' and I forgot to check it back in, no other user could access the file! The other side of the coin means that, if a bunch of users have read/write access to the repository, anyone can update their versions at any time. *yikes!*

Soooooo, like anything, it's no magic bullet. It's not a substitute for people communicating with each other what they've been modifying and why. For example, if I change a function parameter protocol in foo.c, and another person is writing a program using the functions in foo.c (which is also maintained in the repository), CVS will not flag Lee that the function protocols have changed -- even after Lee updates the repository with his new program. Lee will only find this out after he inquires about an updated version of foo.c in the repository (where he will see that the function protocols are different than his version).

next tutorial