Section 1.2. Why CVS?

1.2. Why CVS?

With all the version control systems available, why choose CVS? If you work with files that change over time, the most important thing is to have some kind of version control: after the first time it's saved your bacon, you'll never want to work without it. If it's your first time with a version control system, choose one with good documentation and the features you think you'll need for the first year or two. Read the available tutorials and quickstart guides, and use a system that you feel you can understand. As you're already taking a look at this book, CVS is a fine choice: it will get you through that first year or two, and beyond.

Any version control is better than no version control.

Once you're used to working with version control, you can make a more informed decision about the features you'll want long term, and choose a system with those features in mind. Changing systems is not something to fear, as there are tools for conversion between many version control systems. At worst, you can use one system for the old data and another for the new, or write a script that checks out each revision in turn from the old system and commits it to the new.

1.2.1. Features of Version Control Systems

Every version control system that I'm familiar with records the changes in a document, enables you to retrieve older versions of the document, and enables you to display the differences between versions. (The first two features are what defines a version control system.) Some systems do little more than that, but most have additional features. You should choose a system based on the features that are most important to your project and working style.

One of the most important features a version control system can provide is support for multiple developers. There are two common models for this support; choose the model that works best for you. The easiest to understand is exclusive development: the version control system permits only one developer at a time to work on any individual file. A system may have strict exclusive development and make it nearly impossible for a developer to work on a file he hasn't reserved, or it may have advisory exclusive development and simply warn the developer before allowing access to a file that another developer is editing. The alternative to exclusive development is simultaneous development, where multiple developers can work on the same file and the version control system attempts to merge the respective changes seamlessly. CVS supports both modes, which are more fully explained in Chapter 5.

Traditional version control systems have central repositories, but some of the newer ones have distributed repositories, and many systems have central repositories but support proxying. If you are a single developer, this issue won't affect you, but managers of projects with multiple developers should think about whether a central or distributed repository better suits their needs. See the sidebar "Central, Distributed, or Proxied" later in this chapter for more information.

Systems should support remote access to the repository, or remote connection among distributed repositories. Most projects will need the ability to access the repository from outside the local network. The remote repository support in CVS is explained in Chapter 8.

Another important feature is data export. An exported set of data should not contain administrative files or data for the version control system. Most version control systems provide some form of export. CVS's export command is explained in Chapter 7.

Customization is also important to many users. For example, some project managers want every change exported immediately to a test area. Some want committed changes reviewed to ensure they meet project standards. A proxy repository may need to initialize or finalize a connection when it communicates with the master repository. To achieve all these (and other) special tasks, a version control system needs hooks. A hook is a place to hang a script, such that the script is run at a specific stage of the version control processperhaps before or after a change is committed, when a log message is stored, or when a file is checked out for exclusive development. CVS has hooks in the form of scripting files, explained in Chapters 6 and 7.

Internally, revision control systems usually keep numeric identifiers for each revision. One very useful feature is the taga symbolic name applied by the user. It's much easier to remember that alpha_0-1 is your first alpha test than to remember that it's revision 1.17. Most systems that provide tags allow you to apply the same tag to either the files you specify or to a full project with one command. Tags are explained in Chapter 4.

Branches enable you to run two simultaneous lines of development on the same project, stored in the same repository. The most common use is to separate out a bugfix branch independent of the main development branch. Some version control systems also have a vendor branch feature, a special branch that lets you store data provided by a third party. Branches are explained in Chapter 4, and vendor branches in Chapter 7.

A feature that CVS doesn't have, and that many teams like, is atomic commits. This feature ensures that while one person is committing changes to the repository, no one else can. Thus, each commit is a separate process, and the repository is never in a state where it has mismatched filese.g., one directory with Bill's latest changes, and one with Sally's. CVS has atomic commits on a directory-by-directory basis, but not true project-by-project or repository-by-repository atomic committing.

You may need data encryption, user authentication, and other security features. You need to be able to back up the repository and restore it to a fully working repository easily. To learn about CVS's security and backup capabilities, see Chapter 6.

If you use a particular development suite, your choice of version control may be affected by whether the suite supports the version control system. Another factor might be the availability of programs such as web (HTTP/HTML) viewers or project management tools. Lists of some of the tools available to CVS and development suites that support CVS are in Appendixes A and B.

1.2.2. Comparing Version Control Systems

Table 1-1 compares the features of various version control systems. This table is based on the information provided in their web sites and other available documentation at the time of writing, and on discussion with friends who have used the systems (in cases where I haven't).

Central, Distributed, or Proxied

CVS and other traditional version control systems use a central repository. This means that the historic data about project changes is stored in a single place. Typically, developers have a sandbox, or working area, on their local computer, which contains the version that they are currently working on and which they update from the central repository.

Bitkeeper, Arch, and some other new systems use distributed repositories. Each developer has a personal repository, and the repositories update from their peers. In some cases, the system treats each repository as equal, and whether a project has a master repository is up to the project's lead developers. In others, there is a master repository that has children, each of which may have children, which in turn may have children, and so on recursively.

Proxied repositories are an intermediate form. There is a central repository, which holds the changes data, and proxy repositories, which are used for read requests and which refer write requests to the central repository. Some systems support only reading from proxies, and some projects choose to use only read proxies and have all writing done directly to the central repository.

Each style has advantages and disadvantages. Proponents of distributed repositories say that they're easier to use in very large projects, as access to the central repository can become congested. You can also stage work, keeping a section of work in a secondary repository until it's been thoroughly tested and only then committing it to the master repository.

Something that I consider a disadvantage of using distributed repositories is that it encourages large mergesit's very easy to keep committing to a local repository for a long time, then try to commit an entire feature set to the main development strand at once. If this is taken into account at the project management stage, it's not a problem. If it isn't taken into account, trying to blend the changes seamlessly can require a lot of unexpected work.

In a central repository system, your data is all in one place, which makes it easier to secure it and plan backups. If you choose to, you can stage work through branches. Congestion can be a problem in very large projects.

Using proxies reduces congestion in a central repository system. The proxies take the load caused by read requests off the central repository (save for the read requests used to update the proxy repositories) and, depending on how the proxy system is implemented, may also be able to reduce the write load.

Table 1-1. Version control systems compared

VCS	Development model	Repository type	Atomic commits	URL
CVS	Simultaneous or exclusive	Central and proxied	No	http://cvs.nongnu.org
Bitkeeper	Simultaneous	Distributed	Yes	http://www.bitkeeper.com
ClearCase	Simultaneous or exclusive	Central or distributed	N/A	http://www-306.ibm.com/software/awdtools/clearcase
Git	Simultaneous	Distributed	Yes	http://git.or.cz
GNU Arch	Simultaneous	Distributed	Yes	http://www.gnu.org/software/gnu-arch/
Perforce	Simultaneous or exclusive	Central	Yes	http://www.perforce.com
Subversion	Simultaneous or exclusive	Central	Yes	http://subversion.tigris.org
Visual Source Safe	Exclusive	Central	No	http://msdn.microsoft.com/ssafe/

It's well worth it to read the Wikipedia articles on revision control systems. Wikipedia has a more complete list of available programs, as well as links to their home pages and to other peoples' comparisons of systems they have worked with. The main article is available at http://en.wikipedia.org/wiki/Revision_control.

1.2.3. CVS Versus Subversion

Subversion is designed to be "CVS, only better." It has support for binary files built into the design, permits versioning of directories as well as files, allows you to rename files with a simple command and to maintain their history, and has atomic commits. It works just like CVS does. So why not change to Subversion?

I've been looking at Subversion, and it's not quite true that it's "CVS, only better." It's "CVS, only different." It uses a different repository structure, different methods of remote access, different administrative commands, and different hooks. It currently doesn't support proxying or GSSAPI (Generic Security Services API, a client-server authentication system), and many of its commands, such as diff, have fewer features than CVS's versions of those commands.

I like Subversion, and I think it has potential, but it's not a direct replacement for CVS. It's similar, but it's different enough that some people prefer to use CVS for its feature set, and others prefer Subversion for its feature set.

1.2.4. CVS and CVSNT

CVSNT is a different system; it split off from CVS around version 1.10. Both projects have changed significantly since then. CVSNT can merge binary files, and has several Windows-specific bonuses such as use of DLLs (dynamic link libraries) for sophisticated trigger actions when a change is committed. CVS has gone in a different direction, and has added support for PAM (pluggable authentication modules), created proxying, and provided more scripting file hooks.

1.2.5. Why I Prefer CVS

CVS is free. That's a really good start for small projects, free software projects, and small businesses, and most of my work has been in at least one of those fields. I've also been able to use existing servers for all the CVS repositories I've administered, and to use sites like Sourceforge or other open source hosting sites for CVS repositories for open source work. The total cost of the CVS system has been trivial, for me.

CVS is a mature system. It's solid and reliable, and I've seen it fail only when I misunderstood how it workedwhich happened only when I was first learning it. That's one reason I wrote this book: by explaining the things I've learned, hopefully I can prevent other people from facing the problems I faced.

CVS has all the functionality I need. Most of that is built in, but because it's such a mature system, there are third-party tools that do most of the things it doesn't. For instance, if you want strict exclusive development, you can use the rcslock program. If you need finer-grained security, there's the cvs_acls script. Web browsing of your repository? ViewCVS.

CVS is familiar. It's widespread and has a huge user base. In my experience, members of my team have usually used CVS before, which saves time spent on training.