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.
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).
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.