< Zurück | Inhalt | Weiter >

8.2.11 A Quick Look behind the Scenes

If you are one of those people who worry excessively about efficiency, let us re- assure you that CVS is OK. You could think of a CVS repository as saving each revision of a file (for example, versions 1.1, 1.2, and 1.3), but in fact CVS only keeps a single full version of a file—the latest version—and then stores the deltas, that is, changes required to revert back to the previous versions. So it keeps a full version of 1.3, but then only the differences between 1.3 and 1.2


8.3 A GUI: jCVS 211

and the differences between 1.2 and 1.1. This means that it is always very effi- cient to get the latest version of any file. (Other systems have tried keeping the original and the deltas for each revision going forward—but that gets very ex- pensive to retrieve versions with hundreds of modifications. With CVS, the latest version is always at hand.)

An exception to this are “binary” files, those on which CVS can’t do key- word substitutions. The revisions of those files, such as JPEG image files, won’t be stored by deltas, but by complete copies of each revision.


If you are a die-hard GUI kind of developer, and aren’t yet convinced of the power and convenience of the command line, then reread Section 1.3.10. If you are still not convinced, that’s OK—you can still use CVS with the help of a GUI written entirely in Java. This is an implementation of the CVS client, that is, the portion of the CVS system that communicates with a remote server. The server does the real work of managing the versions; the client collects the data, manages the local files, and communicates with the server.

If you’re going to use jCVS, you will need to get a CVS server up and running—or maybe your project administrator has already done that. If so, read on.