WinCVS Introduction

Installing WinCVS

Installing CVS Integration for Visual Studio

Working with WinCVS

Working with CVS from Visual Studio

CVS Home Page

A quick disclaimer: The following pages were written when we were all still using RedHat 6.x. RedHat 7.x uses xinetd, so some of the instructions regarding how to set up CVS on your server will be useless. I have yet to update these documentation pages to take this into account. Still, this introduction does give you a good nuts-and-bolts introduction to CVS and how it can help you manage your software development project without forcing you to use Microsoft SourceSafe (which, apart from being rather expensive and unusable on anything but Windows, is prone to strange accidents and mishaps - some of which can be quite destructive to your code base).

I had placed downloadable binaries for WinCVS and TCL here on Kryptonians, but I eventually realized that these things are in a state of continuous flux, so it might be best to point you to the lastest versions rather than have you download the stale ones. CVSin is also available through a link on WinCVS.Org but as it is a bit harder to access to its home site, I've left it on Kryptonians for now.

Also: One or two daft buggers have seen fit to lift portions of this tutorial, including the screenshots I took of the installation in progress, without consulting me or asking my permission to do so. Although this information certainly isn't copyrighted, it's only common courtesy to ask permission anyway. Additionally, if you're going to rip my work and post it as your own without crediting its source, at least have the decency to rip the entire site. The whole point of doing this was to help people. Ripping the tutorial into little pieces, stripping out the hints and tricks and putting it up only dilutes the original work and does a true disservice to those who found your site because they actually needed to know how it all works.

"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. In use in one form or another since 1982, it can manage shared access to source code either on a local filesystem or by participating in a client-server relationship. It does have the weakness of being a command-line utility, however. Several GUI front ends have been written for CVS, in everything from Pascal to TCL, on perhaps a dozen operating systems. The most feature-rich and powerful of these for the Windows 98/NT/2000 is WinCVS. If you proceed from here, that's what you'll be installing.

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. You can place "watches" on files in the repository to get up-to-the-minute information on activity for those files, and even get a report on who else is watching those files.

Installing WinCVS is only slightly more complicated than installing Microsoft SourceSafe.
Here is what you need to do to get started:

Get an account on the CVS server. If you're a programmer at a company that uses CVS, this may already have been done for you. (If it hasn't been, contact your sys admin and he'll set you up.) Nevertheless, it is wise to make sure your account works before you proceed. A login account on a Linux box is not the same as a CVS server account. It uses a separate user table.

Install WinCVS. This entails installing TCL/TK and an add-in for Developer Studio as well. It's not difficult. The hard part is getting it set up on the server, and that's already done for you.

Establish a 'sandbox' on your local machine. This is the area to which all your source projects will be downloaded from the CVS server. It can be anywhere you like, including the root of one of your drives (I'd recommend against using C: drive for maintenance reasons).

Start WinCVS and configure it. Under View/Browser, set the current browse location to the location you've designated as your sandbox. (If you want all your code off the root of D: drive, for example, browse the root of D: ). There are a few settings you'll need to check, but other than that, you're ready to begin working with WinCVS

CVS saves its version-control information in RCS files stored in a directory hierarchy, called the Repository, which is separate from the user's working directory. Files in the Repository are stored in a format dictated by the RCS commands CVS uses to do much of its real work. RCS files are standard byte-stream files with an internal format described by keywords stored in the files themselves.

To begin work, you execute a "checkout" command, handing it a module name or directory path (relative to the $CVSROOT variable) you want to work on. CVS copies the latest revision of each file in the specified module or directory out of the Repository and into a directory tree created in your current directory. You may specify a particular branch to work on by symbolic name if you don't want to work on the default (main or trunk) branch. You may then modify files in the new directory tree, build them into output files and test the results.

When you want to make your changes available to other developers, you "commit" them back into the Repository. Other developers can check out the same files at the same time. To merge the committed work of others into your working files you use the "update" command. When your merged files build and test correctly, you may commit the merged result. This method is referred to as "copy-modify-merge", which does not require locks on the source files.

At any time, usually at some milestone, you can "tag" the committed files, producing a symbolic name that can be handed to a future "checkout" command. A special form of "tag" produces a branch in development, as usually happens at "release" time. When you no longer plan to modify or refer to your local copy of the files, they can be removed.

Unlike other revision control packages, you can also "branch" your code off and use CVS to keep track of your changes before merging the finished code back into the main project. This gives you the protection of source control while you tinker, without breaking the build for the other people working on the project with you.

SPECIAL NOTE:

CVS can use either reserved checkouts, or unreserved checkouts. A reserved checkout is what SourceSafe does by default. This situation is best for allowing only one programmer access to a source file at a time. In effect, files are 'locked' until they're 'unlocked' (and there are controls in WinCVS for this). CVS, on the other hand, defaults to unreserved checkouts, which is similar to SourceSafe's multiple checkout. It is possible to set a CVS repository so that simultaneous work on a single file by multiple programmers isn't possible, but the question of whether this is desirable or not is left as an exercise for the reader.