Linux DevCenter    
 Published on Linux DevCenter (http://www.linuxdevcenter.com/)
 See this if you're having trouble printing code examples


Easing Web Application Development with CVS

by Oktay Altunergil
01/24/2002

Web applications, by definition, work in conjunction with a Web server to perform a variety of tasks, ranging from displaying basic customized greetings to performing complex transactions. Most complex Web applications also make use of a database to store information.

While none of the above are radically different when developing a traditional standalone application, a Web application developer might think CVS is designed for working on traditional offline applications. I know I thought like this until I realized how applicable CVS is to Web development and how useful it really is.

One of the more important differences between the two types of applications is the notion of a "working copy." A standalone application developer can usually transfer a set of source files to his own development machine, compile it, and expect it to work. There's usually minimal configuration required each time a new version of the source is used. On a Web development environment, however, there are differences, stemming from the client/server nature of Web applications. These applications usually require the presence of a certain environment. The environment can consist of the environment variables on the server, variables specific to the Web server application, and the database that is being used. Again, some of these also apply to standalone applications, but are more visible when programming for the Web.

It is possible to increase productivity and speed up Web development by making use of facilities that CVS provides.

This is a case study on how to make the most of CVS in a Web-application development context. What I will describe here is the environment that I have set up to satisfy our particular needs and, as such, does not cover all possible scenarios, nor does it go into depth about how to set up a CVS server or use CVS commands, for which there's a lot of documentation available (see links below).

Here is our scenario:

A Windows & Unix shop developing PHP and MySQL Web applications. Each employee has access to either Windows, Linux, FreeBSD, or all of the above.

Some developers are more familiar with Windows tools such as advanced text editors and graphical diff viewers, and they usually want to test their code on a Windows-only Web browser. These people should still be able to use their favorite development environment. On the other hand, if others choose to develop on Unix systems, they should also be able to do it without a problem. It is also desired that people can work from home or other offices with minimal hassle.

Prerequisites:

Preparing the Work Environment

After initially toying with the idea of having one development environment on which all developers would work and test their changes, I've decided to create a separate working environment for each developer. My reasoning was: it is very easy to create a separate virtual host on the Web server and keep one developer's working copy separate from that of another's.

By its nature, Web development requires a lot of testing at each step. Even getting a page to display right might require an extensive amount of coding, testing, and recoding. Having a separate environment gives the developer the freedom to do whatever he wants, without causing other developers any trouble.

On our project, we opted for using the same instance of the database, because the code is not very dependent on the actual data in the database. As long as the database structure is the same, we can share the same database without a problem, since the actual data in it is test data anyway. If we need to, we can easily get the latest state of the database from whoever made the change by inspecting differences in the MySQL structure dump for the two databases.

The Repository

Related Reading

CVS Pocket Reference CVS Pocket Reference
By Gregor N. Purdy
Table of Contents
Index
Full Description

The repository can be on a separate server that doesn't have a Web server installed or it, can be on the development server itself. We have opted to run the development server and the CVS server on the same machine. Since the CVS repository is a separate entity, it will not be affected at all by this.

Although some of our developers work on the development server, I have placed my working directory on my Linux desktop, which I am also able to access via SAMBA from my Windows desktop. This way I have a self-contained development system and native access to both Windows and Linux tools. I have also set up a MySQL database and Apache with PHP on my Linux desktop.

If you're working on the same server as the CVS server, everything is straightforward. All you have to do is check out the source code into your working directory once. After that, you can update, add, and commit source code locally by running the appropriate CVS commands.

However, if you'll be placing your working directory on a different server like I've done, there are a few more configuration changes you have to make before you can successfully use CVS.

The optimum solution I came up with was to use SSH to talk to and transfer files to and from the CVS server. In order to do this, you should first install the SSH clients on your desktop. This will work both on Windows and on Linux, but I will talk about setting up Linux here. After installing the SSH clients, you'll need to set up a few environment variables so you don't have to enter the CVS server info every time you initiate a CVS command.

The first environment variable to be set is the CVS_RSH variable that determines the transfer protocol to be used by CVS.

On a system using a BASH shell, this would look like:

export CVS_RSH="ssh"

The next setting is the CVSROOT variable, which takes care of all the CVS server information, including the username, host, and the path to the CVS repository on the CVS server.

export CVSROOT=":ext:username@cvsrepos_hostname_or_IP:/path/cvs_project"

You can put the above in an initialization script such as rc.local or a per-user login script such as .bash_profile.

The same environment variables also apply to Windows systems (see links below).

After the SSH client and the above environment variables are set, all you have to do is go to the directory on your development server where you would like to place your working copy of the source code and run:

cvs checkout module_name

At this step, you will be asked for a password unless you set up a host-based authentication mechanism to the SSH server.

Related Articles:

Introduction to CVS -- Jennifer Vesperman explains CVS, the Concurrent Versioning System, which is a popular system for storing and version-controlling files. This first article is intended for folks who will be using CVS already installed on a system. Jennifer explains check-out, update, adding, merging, and other functions.

CVS Administration -- Jennifer Vesperman explains how to create and manage a CVS repository.

Setting up host-based SSH authentication is easy. All you have to do is generate a key for yourself using the ssh-keygen command, making sure not to specify a passphrase or a password, and append the public key created to the appropriate authorized_keys file on the CVS server. The authorized_keys or authorized_keys2 (depending on which SSH protocol you're using) file will be in the ~username/.ssh/ on the CVS server.

After the environment settings and the host-based authentication is in place, remotely using CVS is absolutely the same as using it locally on the CVS server itself, which is a real blessing.

If you've set up your working environment as above, you can edit your code on Windows or Linux, commit your changes to the CVS repository using the same commands as you would on a local CVS server, regardless of where you're executing the commands. You can also run the development environment on a Windows machine, but I'd rather not do that, since our production server is running FreeBSD. (Well, this is not the only reason but that's OK :))

You might be thinking "Why bother?, why not just keep developing without CVS?" Here are some real-world answers to these questions.

Here are some relevant links if you would like to go into the details of CVS:

Setting Up and Using CVS:

Setting up CVS with SSH Access on Windows:

Oktay Altunergil works for a national web hosting company as a developer concentrating on web applications on the Unix platform.


Return to the Linux DevCenter.

Copyright © 2009 O'Reilly Media, Inc.