If there's one thing I admire most about Linux, it's the fundamental difference between it and other operating systems in terms of cost and availability. Other than BSD, there is no other operating system around that will let you own, run, and modify it to your heart's content without spending a dime. From downloading programs and ISOs from the Internet to messing around with the source code for your favorite application directly, Linux allows you to do it all through the beauty of Open Source.
For this reason alone, Linux and other Open Source operating systems and programs are favorites for programmers. The freedom of code is wonderful for any programmer, allowing you to view other people's source code without cost or repercussion. Because of Open Source, we have many more budding programmers as well.
However, as any programmer knows, dealing with source code and programming in general can sometimes be a confusing and hazardous experience. Ever have a good, solid code base for one release and then start implementing new features that end up breaking everything and making a huge mess? I have, and it's not fun. Backups of previous stable versions are fine, but there are more powerful ways of covering your tracks. One of these is by using Source Code Management tools, and I will introduce you to one such tool right now.
CVS, the Concurrent Version System, is an Open Source source code management tool that was designed to allow multiple users to work on the same file at the same time using a shared directory. Using CVS, multiple users are allowed to check out files from a specific directory tree, make changes, and then commit those changes back into the same directory using a centralized repository for the source tree.
Because of this, CVS really shines when used by multiple users as it can merge differences from each user and make a single source tree as the end result. CVS also tracks the differences across revisions, so you can easily back out to a previous, stable revision at any time. You can also check out the code from specific periods instead of merely checking out what is current. CVS provides a logging mechanism as well so that users making changes can enter into the log what they changed and why, making life easier for their compatriots.
This is one reason CVS is often chosen by programmers of Open Source projects with a number of authors or users contributing to the project. With CVS' ability to manage large, distributed software development projects, developers located around the world can easily collaborate to build a program together in a logical and coherent fashion. The old-fashioned method of sending diff files to other programmers to incorporate into their own code base is largely made obsolete by using CVS. With older methods of source code exchange, keeping track of changes made by different developers was practically impossible. CVS keeps track of who made which changes by allowing developers to work on their own local copy of the original source and merge their changes into the main code tree. With this method, developers can also update their local code base to the current version in CVS so they are always kept up-to-date with what others have done.
CVS supports what are called "code branches," as well, which are basically branches off the main source code tree. This is useful for working on a new version of code and retaining the old code in CVS to facilitate easy bug fixes in older revisions of the source. CVS comes with the built-in ability to manage version numbering and tagging for source files, which allows developers to easily work on new branches of the source code while keeping track of the main code tree and even other simultaneous branches. With this mechanism, programmers can also merge the code branches back into the main tree at a later date.
While this may not mean much to anyone other than a programmer, CVS does wonders for other projects besides source code projects. CVS can be used to control source files for Web sites, with each HTML page subject to the same rules as any piece of source code. In fact, CVS also works exceptionally well for handling documentation such as manuals or books. Basically, any straight text file can be managed by CVS, regardless of the type of file. CVS knows nothing about file contents beyond a few special key words, and this makes CVS a very flexible tool indeed. The only difficulty CVS exhibits is in dealing with binary files such as graphic files, compiled source code, music files, and so forth. CVS can still store those files, but it doesn't provide the same revisioning capabilities it does with regular text.
There is another tool, the Revision Control System (RCS), which provides the same functionality but at a single-user level. We will take a look at RCS in the future, as it may be better suited for you than CVS. Sometimes CVS can be overkill for simple single-authored projects. Take a look at the home page for CVS.
Many distributions provide a packaged version of CVS, so you may already have CVS installed, or you may be able to install it from your distribution's install CD. If this is not the case, visit the CVS Web site and download the source for CVS. CVS is not only available for Linux, however; you can also download a version for Windows and for other UNIX platforms. In fact, CVS has also been ported to a few other operating systems such as OS/2, MacOS, BeOS, and even DOS! So, regardless of what operating system you use, you can make use of CVS anywhere. To download the source code, visit this ftp directory and download the file cvs-1.11.tar.gz. Save this file to your /usr/local/src directory and unarchive it using:
tar xvzf cvs-1.11.tar.gz
You will have a new subdirectory called cvs-1.11/ now, so change into that directory and prepare to compile. Use the following command to install CVS into your /usr directory tree:
CVS is now installed! If you wish to instead install it into your /usr/local directory tree, simply use this configure command instead:
The next step is to configure CVS for your system. You will need to decide where to store the central CVS repository, a single directory in which all CVS projects are stored. Be sure that the directory you create for your CVS repository has plenty of room because a lot of information will be stored there. Remember, CVS tracks differences in source files and maintains a log and version records, so over time, your CVS repository may grow quite large, especially if you maintain a number of projects in it. For the sake of the following examples, we will install the CVS repository into the directory /usr/local/cvsroot. Create this directory and then create the CVSROOT variable, which should point to your primary CVS repository. You can do this immediately by using:
However, you will want this variable to become somewhat permanent, so I suggest editing the system-wide BASH initialization script (assuming you and your users use the BASH shell), which on a Linux-Mandrake system is the /etc/profile file. Some other distributions may use a different filename for this file. You can also edit your personal ~/.bash_profile file in your home directory to add the same commands:
After this, any user who logs into the system will have the $CVSROOT variable pointing to your centralized CVS repository.
The next step is to initialize your repository. You do this with the CVS command init. For example:
Or, if you are setting up a second CVS repository for a special reason, you can tell CVS to ignore any $CVSROOT variables and use the directory specified on the command line like this:
cvs init -d /usr/local/cvsroot
With the cvs init command, CVS creates a new directory called /usr/local/cvsroot/CVSROOT, which is where the administrative information on the repository is kept. Of course, if you used a different directory for your repository, the CVSROOT directory will be created below it. Once you have completed these steps, you are ready to begin adding code to your repository.
In this Daily Drill Down, we looked at some of the reasons that using a Source Code Management tool like CVS can be helpful. CVS is a valuable tool for many people, not just programmers, as it will assist writers or Web designers in keeping track of their own projects. In the next Daily Drill Down, we will add a project to the repository and learn how to make use of CVS to help maintain our code. Also, in the future we will take a closer look at RCS for those who don't need to make use of the multiuser capabilities (and complexities) of CVS but who still want the same basic features.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.
Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.