Team LiB
Previous Section Next Section

Hack 86. Grab the Latest Source Code

Source code is the lifeblood behind any open source project, and its welfare is critical in pushing the code forward and improving it. To the nonhacker, this random collection of phrases and letters appears to be gibberish, but to the hacker, this code makes perfect sense. To remain productive, it is essential that hackers maintain their code in a clean and useful state. Although many hackers worry about keeping the source code usable, this is difficult when you consider that multiple developers from around the world working on a project hack a single set of source code files. These projects rarely have a single lead developer who decides what goes in and out of the source code tree, so how is this development managed?

The solution to this problem is a source control system. These systems essentially provide a metaphorical railway signal box to manage the different needs of the different hackers. The system stores the code in a repository on the server and allows access to only those users who have an authorized login account. With an account, users can copy a snapshot of the code to their computers (this is called making a working copy), hack the code, and then submit the changes to the main server. The source control system ensures that users cannot commit changes at the same time, and it only commits the differences made to the code back into the system. This ensures that bandwidth is not bogged down by the same content flying back and forth between the hackers and the source control server.

In this hack, you are going to get started with a popular source control system called CVS. This tool is in use by most of the large software projects, and you can use it to get read-only access to the developers' source code servers. This code can be useful if you want to explore the possibility of hacking on some code yourself, but it is also handy for those of us who like to compile unstable development code to see just what the hackers are putting in the software. For example, using the methods described here, you can compile the development branches of KDE or GNOME for a bleeding-edge desktop [Section 5.11 and Section 6.5].

9.18.1. Connect to a CVS Repository

To use CVS first you need to specify where the CVS source code server is located. You do this by setting an environment variable called $CVSROOT. This variable is often set in your shell's startup file (such as .bash_profile for the bash shell), but if you are unsure of which shell you are running, type the following command to see which one it is:

foo@bar:~$ echo $SHELL

You need to specify a $CVSROOT that indicates the location of the CVS server, the username to connect with, and where the code is stored on the server. The $CVSROOT is set as an environment variable with three distinctive parts:

[authentication type]:[user@location.domain]:[location of the code on server]

If you want to connect to the KDE CVS server, for example, you can get read-only access in which you can just download the code by using the anonymous username. Many CVS services offer an anonymous user in which onlookers can download the code but not make changes to it.

If, for example, you are using the bash shell, add this line to your .bash_profile to add a connection to the KDE CVS server:

export CVSROOT=:pserver:anonymous@kde.org:/home/kde

If you want to set this value from the command line in a bash shell, you can use this command (good only for your current session):

foo@bar:~$ export CVSROOT=:pserver:anonymous@kde.org:/home/kde

When you have set the variable with one of these methods, you can check that it is working by typing:

foo@bar:~$ echo $CVSROOT
:pserver:anonymous@kde.org:/home/kde

With this complete, now you can log in to the CVS server. To do this, type:

foo@bar:~$ cvs login

You are prompted for a password. Just press Enter to use a blank password. Now you are returned to the prompt.

Considering the vast amount of different open source projects and the huge amount of code sitting on the Internet in CVS servers, you might want to use different CVS servers. To do this, you need to set your $CVSROOT to the new server and log in again.


On a CVS server, code is grouped into modules that contain code for related projects and tools. For example, the KDevelop project is contained within the kdevelop module on the KDE CVS server. You can see a list of these modules by typing:

foo@bar:~$ cvs co -c

To get a module from the server, you need to check it out using the CVS co option. For example, you can check out the kdevelop module with:

foo@bar:~$ cvs co kdevelop

Then you'll see the code checked out to your computer, one file at a time. To update your local copy with the latest changes from the CVS server, you need to go into a checked-out directory (such as the kdevelop directory in our example), and type:

foo@bar:~$ cvs update -PAd

When you run this command, only the files that were changed since your initial checkout will be copied to your computer. This ensures that a minimal amount of bandwidth is used for keeping your code current.

CVS is a powerful and competent source control system, but it is also one of the most confounding pieces of software to use, particularly when adding files to a server. For more information, I recommended you read the free book Open Source Development with CVS at http://cvsbook.red-bean.com/.

9.18.2. New Kid on the Block: Subversion

Although CVS has been around for a long time and a lot of open source projects use it, it has some limitations which some developers find frustrating, including not being able to store metadata (properties) associated with files and not being able to properly version directories. An alternative system called Subversion, which overcomes these limitations, is rapidly taking over as a replacement for CVS, and many projects now provide access to their source code using Subversion.

The command for accessing a Subversion repository is very simple:

foo@bar:~$ svn checkout http://repo.example.com/project project

This will check out the latest copy of the project tree into a local working copy named project.

Then you can keep your local source tree up-to-date by entering it and typing svn up, which will fetch any files that have changed since your last update and will merge the changes into your local tree.

The Subversion project is very active and has a very helpful mailing list. You can find the main project page at http://subversion.tigris.org, and you can also access the free book Version Control with Subversion at http://svnbook.red-bean.com.

    Team LiB
    Previous Section Next Section