A CVS repository holds the current files, and every contributor keeps their own local copy, named working folder. One can add his modifications to the CVS main repository (a process called "committing") and/or update his own copy to reflect recent changes made by other contributors. This article will show you how to manage your CVS repository using Cervisia, a easy to use CVS front end.
The main repository can be set to hold your own project, if you wish to use the nice revision control features of CVS. It is easy to set up a local repository, and you will gain the ability to:
- Easily revert to a previous version
- Track problematic changes
- Avoid accidental loss of information
- Experiment with your work while maintaining a more conservative version
- Easily view (and review) the changes done by others
But you will get the most from CVS when the majority of the documents or files are saved as text files, because many of the CVS features are related with manipulating text. It is not surprising that version control systems are very popular with programmers and web developers, who work constanlty with text files.
The version control paradigm is very useful for non programmers, since we all do collaborative work at our jobs, in the universities, schools, etc... and complex personal projects can also benefit from its features. But text files saved in binary format (for example, OpenOffice.org and Koffice files are compressed) are unfortunately handled as binary files. Even when using text documents like .html, .rtf and xml, the format information (html tags, etc) restrict the user's ability to read the raw source of the document, and therefore the raw changes (differences) that CVS outputs.
In an ideal world, the users would have the option to view the content, and not raw information for text and binary files for every CVS feature. But to reach this goal, the applications should be CVS aware, or in other words, able to parse the files and differences in a sensible way. As you can imagine, depending on the file type and application, this feature is not easy to implement. Let's not drift too much here, discussing these issues is out of scope of this guide.
The objective of this guide is not to cover all CVS functions and commands, but to quickly inform the user how to perform the most common tasks. For instance, you shouldn't have to memorize cvs command line arguments to help with documentations to an open source project, to download the sources of a program you want or to create and use a repository to enable collaboration features inside your company.
Cervisia is a version control system front-end. It aims to support CVS and other version control system programs in a unified interface. Currently, it offers several features, like conflict resolution, differences and history viewer, status for the working folder files, and support for the most used CVS functions. You can get Cervisia installing the kdesdk package (and the cvs package) using your distribution tools. The version of Cervisia used for this article is the 2.1 version, released with KDE 3.2.
When you are dealing with a CVS repository, the most common actions are:
- checkout: copies the repository data creating a local working folder.
- update: fetches the latest changes from the repository to your working folder.
- difference: creates a file containing the differences between your working folder and the main repository.
- add: tells cvs to add the specified file(s) or folder(s) (that already exist on your working folder) to the main repository on the next commit command.
- remove: tells cvs to remove the specified file(s) or folder(s) from the main repository on the next commit command.
- commit: apply to the main repository the modifications, additions and removals from the working folder.
Cervisia's options are dictated by its own configuration, not by CVS usual ".cvsrc" file. Cervisia has very sensible defaults, so we won't need to configure it.