Concurrent Versions System

CVS is an Open Source version control system for (primarily) text files. See http://www.cvshome.org. The NT version of CVS can be found at http://www.cvsnt.org.

Pros:

• Open Source. Very widely used, and thus pretty darn stable.
• Can be run in client/server mode, which is safer than sharing the database files over the network. (VSS needs a third-party add-on to do this; PVCS is strictly based on file sharing AFAIK.)
• Pretty good branch/merge model.
• Several different client GUIs to choose from.
• Day-to-day functionality (get aka checkout, update, commit) is pretty straightforward.
• Numerous tools available to help with merges and diffs; these are all external to CVS so you get to pick and choose what you like.

Cons:

• Source is very old, few new features coming out.
• Missing the concept of "change sets". (Perforce has this; VSS & PVCS do not.) This is a much better model of checkins, IMO. A change set is set of files, all part of one guaranteed atomic checkin with one description. Change sets are tracked and remembered, and are the unit of change (instead of file revisions, as in most systems).
• Client GUIs are pretty different from VSS, making the transition a bit hard.
• Terminology a bit odd in a few places. CVS's "checkout" would be called "get" in most other systems; "update" is VSS's "get latest (which is distinct from the initial get/checkout).
• Binary file handling can be tricky. (This is a problem in most systems though.)
• File deletions and renames (or more generally, any operations on directories, as opposed to file contents) are awkward or have limitations. (More detail would be good.)

The basic CVS software includes only a command-client interface. There are a number of GUI clients available, which are developed independently of CVS itself. If you try any out, please add reviews to this page!

;[WinCVS]: A CVS GUI client for Windows and the Macintosh. Seems to be pretty widely known. ;[TortoiseCVS]: A plug-in for the Windows Explorer, allowing you to perform the most common CVS interactions directly through your folder views. ;[jCVS]: A cross-platform CVS GUI client. (The "j" stands for Java, because this client is written in Java. Typical Open Source project -- users could care less what language it's written in, as long as it runs!) ;[TkCVS]: A cross-platform CVS GUI client. (Tk stands for Tcl/Tk, the UI library used to implement it. Seems to be a naming trend.) ;[SmartCVS]: Another cross-platform CVS GUI client. The developers intend that it provide "the ease of use of Microsoft's Visual SourceSafe". The basic client is freely available, but access to the "professional" features requires a license.

Barely-documented CVS trivia

;cvs checkout .: It can be a bit tricky to get started as a CVS client if you don't know a priori what modules are in it. If you create a sandbox root for yourself, cd to it, and run "cvs checkout ." (note the lone period denoting the current directory), you will get everything in the repository and initialize your entire sandbox area correctly. This is also a prerequisite for being able to use "cvs add" instead of "cvs import" for adding new top-level directories. ;cvs import vs. add/commit: A lot of the CVS documentation describes using import for creating new top-level modules in a CVS repository. However, it's my understanding that import does some special things related to tracking third-party releases in your repository which are otherwise unecessary and confusing, and I've seen a few recommendations against using import gratuitously. You can instead use the usual add/commit two-step process to add new top-level modules, provided you first apply the step described in the previous item. ;commit dates: There seems to be no way of manipulating the recorded commit date of a file -- the date is based on the time of commit. This is unimportant for normal usage, but makes it difficult to migrate sources with history from another source control system. The one Perl script I've seen to migrate from VSS to CVS requires having the RCS executables available, and it uses these to create CVS's underlying RCS files directly, presumably to work around this limitation. Ugh.

WinCVS

DanMuller: You can find a short version of the instructions for installing and configuring WinCVS [here]. WinCVS 1.3 is a little easier to install, but it's a beta. Neither 1.2 nor 1.3 is a one-step installation -- the older version also requires you to install Tcl/Tk to get full functionality, the newer version requires you to install Python. Either will work without their respective scripting language, but you lose some features.

NOTE for WinCVS 1.20 and CVSNT 1.11.1.2: Contrary to the instructions you'll find in various places, copying cvs.exe and cvs2ntslib.dll from CVSNT to the WinCVS 1.20 directory is inadequate. It's easier to just install CVSNT on your machine and reboot it. Or, use WinCVS 1.30, but be aware that it's a beta version.

The biggest initial roadblock to learning these seems to be that neither really shows you the contents of the source code repository, which is what you may be used to seeing in VSS. Instead, they show you your own directories and files, adding information about their relationship to the repository (if any).

For browsing the contents of the repository without reference to your own work area (which you won't have when you start out), it is recommended to install CVSWeb on the server, which I have not done. (There is no Web server on Marge at this time.)

Add reviews and other commentary down here, please...

• Here's a good site for information on using CVS: http://www.devguy.com/fp/cfgmgmt/cvs/
• And here's a [whole online book] on CVS.