< Zurück | Inhalt | Weiter >

Chapter 8


Know What You Have: CVS


image

Source control is such a necessary part of good development practice that it ranks right up there with a sound compiler as a critical part of any software project. It may seem like only an administrative overhead to newcomers, but its effect on a project of any size will be felt over time; it’s not the first version of a project that needs source control so much as versions 2 and beyond. And it can be a life saver.

One of the Linux tools that is most appreciated on projects around the globe is the Concurrent Versioning System, CVS.1 It is one of the best, most reliable pieces of software that these authors have ever used. It should be part of your repertoire of software skills, even when you’re not running on Linux. But enough praise; back to practicalities.

image


image

1. As we were writing this chapter, the core developers of CVS released version 1.0 of a new version control system called Subversion. This new system supposedly contains many improve- ments over CVS. We do not doubt this, and we recommend that you take a look at Subversion before you select a version control tool. Meanwhile, we know CVS, and most Open Source projects are currently managed with CVS. Choosing CVS won’t be a bad choice.


189


8.1 WHAT YOU WILL LEARN


• Why you need CVS—the problem with source code.

• How CVS solves this problem.

• Some basic CVS mechanisms:

• Importing source

• Checkout

• Commit

• Tagging

• Branch tagging

• Status

• Log

• Export

• A quick look at a CVS GUI.


8.2 SOURCE CONTROL: WHYS AND HOWS


Consider the following scenario: A customer has called with a problem in the software that your development team released over a month ago. Your develop- ers try to reproduce the problem on their systems without success. What version of software is your team running? Well, there has been a lot of development in the last month, a lot has changed. Some new features have been added—halfway. In other words, it’s close but not really the same software. And it’s far from being ready to be given to the customer as a fix-release. Well, what’s changed since the release was shipped six weeks ago? Can you find or create a set of sources that matches exactly what the customer is running? Can you then provide a modified version that contains only the fix necessary and no other changes?

With such low prices for hard drives these days it is now economically feasible to track your software releases simply by shelving an entire hard drive with each release of your software. It could contain the source code and all the tools in use for that version. But it does make search and comparisons a bit difficult. Still, conceptually, this is almost what you’d like—to be able to access an image of what your source looked like at any given point in time (for example, when released).


Enter cvs—the Concurrent Versioning System. It’s a versioning system, allowing you to retrieve copies of the source based on either date parameters (e.g., last Tuesday) or the labels that you create. It’s concurrent because it supports multiple simultaneous users.

You may have used a versioning system before that let multiple program- mers work with a set of files. Often such systems will “lock” a file while one user is using it, keeping others from modifying it. CVS doesn’t work that way—or doesn’t have to. Rather it allows users to each modify the same file (truly concurrent), and then reconciles the changes when those changes are made permanent.

To explain all this, it would be best to set down some terminology, as used by CVS.

 


repository

sandbox

checkout

commit

update

tag

8.2.1 Setup

8.2.2 Import

8.2.3 Normal Use

8.2.4 Update

8.2.5 Merges

8.2.6 Log

8.2.9 Branching Tags

8.2.11 A Quick Look behind the Scenes

8.3.1 Installing jCVS