Next Previous Contents

2. Introduction

2.1 Why Use CVS?

Concurrent Version System (CVS) is a tool that enables the following:

From the above it should be apparent that CVS is not just for shared access projects, although that is arguably what it was developed for. There are huge benefits associated with putting any project under CVS at its inception. I always put every document that I ever write (including this one!) under CVS from the very beginning (whether or not it is a "shared project"). If I accidentally delete the working copy, or hit save at an awkward time and break the working copy, or realize after two days of work that I've totally screwed up the working copy, it is not a problem. I can retrieve any previous working version of the document that I've ever checked in.

For shared projects, it is simply essential. As project manager, I don't have to worry about whether or not a project worker totally screws up working sources or finished documents. As a project worker one is protected from all the bad things that can happen when you and a co-worker try to work on the same document at the same time.

For example: you both open the same actual document, you make changes, they make changes, you save your changes, they save their changes and -- your changes all go away as the saved image is overwritten. With CVS, you each work in your OWN working directory, you both work on checked out copies of the same source (at the same time), you both commit your changes, but CVS is smart enough to either MERGE your changes in either order if there are no obvious conflicts or to FLAG the conflicts and require that they be resolved if it cannot see how to merge them before permitting you to proceed.

CVS also requires that you document changes to the project as you go along. This is an essential discipline to master for anyone who expects to revisit their projects more than six months after completion. Every bit of code, every text document, every web document that you ever write is a potential source for future writing. With CVS those sources are both archived and preserved and documented so that you can search them, understand them, and retrieve them for later re-use.

2.2 How To Use this HOWTO

This mini-howto has several sections. Everybody who is reading this to learn to use CVS at all should read the first section, "CVS Overview and Concepts" so they get some idea of what the tool is for and how it "works" by creating archived, timestamped, log/documented histories of the diffs (changes) made to each document since its inception.

If you are learning to use CVS for yourself and projects that you will ultimately manage that might include others, you should read everything from the beginning on, in order. This guides you through setting up a CVS root of your own or to share, and putting new or old projects, for yourself alone or a project group, under CVS control.

If you are joining an existing project already under CVS control and managed by others, after the Overview you can just skim the Setting Up CVS section and skip ahead to "Basic CVS commands".

It is strongly advised that newbies to CVS try to set up their own CVS root directory and try to work though the example commands demonstrated in the howto for a "toy" project, such as creating a project directory named "hello", putting it under CVS control, adding a file to it named "greeting", editing it so that it contains "Hello World!", and committing the changes. Practice adding, removing, updating, committing and so forth on harmless files until you are fairly confident that you "get" how it works, and only then proceed to working with important projects of your own or shared.

As is noted in the text below, it is relatively easy to drop a file by accident when putting an existing project under CVS control (not due to any flaw in CVS itself but because it is easy to make a careless or unknowing mistake). That is why a bit of practice is a good idea. It is also a great idea to make copies of pre-existing projects you are putting under CVS control and hold onto them until the project has been under CVS long enough to be pretty sure you aren't missing anything (five minutes to five weeks).

This isn't much of a burden, though. One of the points of using CVS in the first place is to protect you forever afterward from precisely things like "dropped files" or "deleting your project directory by accident" after making eight hours worth of changes but before the nightly backup is run. When you put all of your projects under CVS first thing, your chance of losing work of any sort due to loss of an important revision image goes way down.


Next Previous Contents