Managing Collective Software Development with CVS and Subversion

The original revision control system (rcs) utility has features to manage small application projects, but when an application grows larger or is maintained by several developers, a better tool is needed. The Concurrent Versions System (CVS) arose to manage a corps of far-flung open-source developers and files that can potentially change on a minute-by-minute basis.

CVS controls the source code by storing it exclusively in one place, called a repository, and setting rules for access to the files. A CVS repository from the client perspective is like an FTP site or other remote access directory. It contains all the files in a particular development project. The difference between CVS and FTP is that a CVS repository is like a library, and FTP is like a bookstore. To work on a file or set of files, you must check them out of the repository and check your changes back in (or commit your changes, in the CVS vernacular). The administrators of the repository can decide whether more than one person can check out a file at a time, how to process multiple changes, when to build the new version of the application, and what files will be included.

With CVS, you can get a complete record of changes in files without having multiple copies taking up space on your hard drive or server volume. Source files can be compared against the list of changes between versions, and any version can be reconstructed for review. Because any version can be reconstructed at any time, bugs can be tracked more easily and better test cases can be developed.

Incidentally, version control isn't good only for software projects. Any electronic file that undergoes frequent revisions or that is grouped with other files in a larger entity (for example, a book and its chapters) might do well to exist in a repository. It is reasonably simple to create a CVS repository on your local drive.

Create a base directory for all your CVS projects, such as ~/cvsroot. Then point CVS to that directory:

cvs -d ~/cvsroot 

You can now add files and directories (projects) to cvsroot, which can, in turn, be versioned over time using CVS. The six key CVS commands are the following:

• add Commit a new file to the repository.

• import Add a batch of new files or projects to the repository.

• checkout Get a file to edit.

• commit Return an edited file to the repository.

• remove Make files currently in the repository disappear (other copies may exist elsewhere, however).

• update In a local repository, confirm that everything is current. In a remote repository, get the latest changes in your working directory.

CVS isn't perfect, however, and in 2001 some CVS developers moved to another project, Subversion, which they hoped would solve some of CVS's nagging problems. This project, designed to eventually replace CVS as the open-source project management tool of choice, released version 1.0 in 2004 and has won many converts.

Both CVS and Subversion work in substantially the same way. Subversion adds several new features, including the capability to track versions of directories, a binary differencing algorithm, and more efficient branching and tagging of new versions of files.

Both CVS and Subversion are command-line applications, but Cervisia provides a GUI front-end to CVS and Subversion for KDE users. It can be used either as a standalone application or integrated into a Konqueror window. Cervisia allows you to connect to your repository and update and work directly with it. Eclipse also has a CVS plug-in that works the same way.