The Apache HTTP Server project keeps all of its source files in a central CVS source code repository. As changes are made, they are applied to this master repository; when a release is built, it is assembled from the same repository. But suppose you want to keep up with the latest and greatest Apache developments (and bugs), without having to wait for a release? How would you do it? That's what this article is all about.

Assumptions in This Article
For the rest of this article, I'm going to make the following assumptions:

1. your Apache source tree starts at ./apache-1.3/
2. your Apache ServerRoot is /usr/local/web/apache
3. your Apache DocumentRoot is /usr/local/web/htdocs
4. the username under which Apache runs (the value of the User directive in your httpd.conf file) is nobody
5. Code examples appear in this typeface. Text you type exactly as shown is bold-face; placeholders for which you substitute a real value are italicised.

All of the cd and other shell commands in this article that refer to directories use these locations.

Ways of Accessing the Source
Members of the Apache core development team have direct access to the repository. When one of them makes a change, it's available to all the others instantly. However, how can that change percolate out to where people who aren't members of the team can get it and try it out? There are currently three methods of doing this; each has its own advantages and disadvantages.

anonymous CVS

This method allows you to keep up by accessing a copy of the master repository. At least two systems currently make such copies at intervals and allow those copies to be accessed using a generic read-only account. This 'generic' account is similar to the 'anonymous' account used to access FTP repositories, hence the name 'anonymous CVS,' like 'anonymous FTP.'
Needs: a CVS client.

tarball download

Synchonising with the sources this way is as simple as pulling down a compressed tar archive and unpacking it.
Needs: a Web browser, the ability to gunzip files, and a tool capable of reading tar archives.

rsync

The rsync tool allows you to keep a local directory tree in sync with a remote one. In this case, you can use it to keep your local copy of the Apache sources in lockstep with one of the readonly copies of the master repository.
Needs: an rsync client.

Since all of these methods are working on copies of the master repository rather than the master itself, the freshness of your source is directly dependent on the freshness of the copy.

Using the 'Anonymous CVS' Method
This method of playing catch-up involves using CVS itself in client-server mode. One or more systems out on the Internet periodically make copies of the master Apache repository, and you use CVS to make a local copy of one of these and keep up to date with it.

Advantages

• Once a local copy is established, updates are small--only changes are copied
• You can maintain local customisations in your copy of the tree, and CVS will merge in changes from the master--and let you know when your changes conflict with alterations made to the master
• cvs diff makes it easy to submit local changes to the Apache project for possible inclusion

Drawbacks

• Requires a CVS client
• Lots of back-and-forth network traffic during an update; can be slow

The currently working anonymous CVS repository is maintained at the Sourcery.Org site. It is refreshed from the master repository every two hours (on the odd-numbered ones).

To obtain ('check out') a copy of the Apache 1.3 source tree, or update an existing checked-out tree, use the following commands:

    export CVSROOT=:pserver:anonymous@CVS.Sourcery.Org:/cvs/apache
    cvs login
    CVS password: anoncvs     [not echoed]
    cvs checkout apache-1.3
  

As long as you don't do a cvs logout, you only need to log in once. If you want the Apache 2.0 source tree instead, use apache-2.0 instead of apache-1.3 in the example.

You can avoid having to set the CVSROOT environment variable every time by cding into the apache-1.3 directory and doing a cvs update instead of a checkout. The main disadvantage to that is that it won't pick up any new subdirectories (and files in 'em) that have been created since the last time you updated your local copy.

Synchronising this way involves using a Web browser to fetch a compressed snapshot of the Apache sources, and uncompressing it and unpacking them afterward. FTP access to the snapshots is not available, only Web access. The main disadvantages of this method are that you get the entire repository rather than just the parts that have changed since your last download, and it's difficult to keep your own changes in the downloaded directory tree.

Advantages

• It's fast: one file to download, and a compressed one at that
• Only common software needed (browser, WinZIP or gunzip)

Drawbacks

• Each download gets the entire repository, rather than just the parts that changed since your last download
• Local modifications must be maintained by hand across downloads
• Generating patch files for submission is un-simple

The snapshots are created every six or twelve hours, and can be picked up from <URL:http://dev.apache.org/from-cvs/>. There is a separate subdirectory for the Apache 1.3 and 2.0 source trees. The snapshot files are named according to the year, month, day, and time they were made; the one at the bottom of the directory listing is the newest. Be sure to compare the file sizes so you don't pick up a corrupt or incomplete snapshot!

To unpack and install a tarball snapshot, use the following commands:

    rm -rf apache-1.3
    tar xzvf apache-1.3_yyyymmddhhmm.tar.gz
  

What you then have is a tree that looks like it was checked out from a CVS repository--because it is. However, since you didn't check it out and the repository is on another system, you can't use the cvs diff command to generate easy patches for submission.

Using rsync to Maintain Synchronicity
The rsync command allows you to do either a massive download or determine what files are changed.

Advantages

• It's reasonably fast: only changed files are copied, and they're compressed during transmission

Drawbacks

• The rsync client is probably not installed by default by your Linux distribution
• If changed files are detected, they are either copied entirely or not -- local changes are not automatically applied
• Local modifications must be maintained by hand across downloads
• Generating patch files for submission is un-simple

The rsync master copies are created every few hours, and you can create a local working copy, or synchronise an existing one, with the following command:

    rsync -avz --delete dev.apache.org::apache-1.3 apache-1.3
  

As with the tarball download method, the result is a directory tree that looks like it was checked out from a CVS repository--but can't be used with cvs diff and other CVS commands because you don't have access to the master repository.

Given the pros and cons of the three methods, I recommend the tarball download if all you want to do is test-drive the latest and greatest. If you want to do a test-drive on a regular basis, I think the rsync mechanism is best. But if you have local customisations, or are considering submitting fixes or features to the developers, you can't beat anonymous CVS.

If you want to stay on the bleeding edge of Apache developments, it's quite easy and even encouraged. Almost all of the tools you need are already included in most of the Linux distributions (if not automatically installed), so all you need is an Internet connexion, some patience, and some fortitude and you're ready to go. Remember that if you decide to do this, you're working from a snapshot of the actual master code, and it's possible that the latest one you downloaded was created midway through a problem (such as a compilation failure) being detected and solved by the developers. That's where the fortitude comes in: wait until your snapshot source refreshes, and then try again.

If you do decide to play keep-up with the Apache project's ongoing development, any feedback you can provide about problems you encounter would be welcomed by the developers--particularly if your report included a fix as well.

Going Further
You can also find some documentation at the following URLs:

• <URL:http://www.cyclic.com/>
• <URL:http://dev.apache.org/>
  (Be aware: this is documentation. The developers are off doing development, not documentation, so this may not be completely up-to-date.)
• <URL:http://dev.apache.org/anoncvs.txt>

Acknowledgements
A security-expert acquaintance from my distant past, Colin Rous, contacted me after the publication of the Apache security article and pointed out that my definitions and uses of "mandatory" and "discretionary" vary significantly--and confusingly--from those used in government and other circles. As a consequence, I'm coming up with different and non-conflicting terms for those things I called MAC and DAC in the article. Stay tuned.

Got a Topic You Want Covered?
If you have a particular Apache-related topic that you'd like covered in a future article in this column, please let me know; drop me an email at <coar@Apache.Org>. I do read and answer my email, usually within a few hours (although a few days may pass if I'm travelling or my mail volume is 'way up). If I don't respond within what seems to be a reasonable amount of time, feel free to ping me again.

About the Author
Ken Coar is a member of the Apache Group and a director and vice president of the Apache Software Foundation. He is also a core member of the Jikes open-source Java compiler project, a contributor to the PHP project, the author of Apache Server for Dummies, and one of the lead authors of Apache Server Unleashed. He can be reached via email at <coar@apache.org>.

discuss this topic to forum