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.
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 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:
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.
You can put the above in an initialization script such as
rc.local or a per-user login script such as
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.
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_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
You might be thinking "Why bother?, why not just keep developing without CVS?" Here are some real-world answers to these questions.
Any number of developers can be working on any file at any time. If more than one developer makes changes on the same file, CVS will either merge the changes or, in the case of changes that were made on the same file, it will prompt you to merge the changes manually. You will never overwrite somebody else's changes like you would if you were using regular FTP.
All changes made to any file are logged and you can revert to any state of the code.
If you decide you want to work from home, all you have to do is set up a similar working environment (maybe on an old computer lying around) and run
cvs update to get the latest version of the code as it was uploaded to the CVS repository by all other developers. You can submit your changes just as easily. You do not have to transfer files manually using FTP.
Since you'll be setting up SSH to access the repository, your transactions will always be secure.
You will code a lot more freely, because mistakes will not affect other developers; others won't be causing you any trouble, either. Furthermore, if either of these happens, you can easily recover the code from a clean state in the repository.
It will be a lot more convenient and fun to code. There's nothing more fullfilling than running
cvs commit and adding the log entry for the changes you have made. I have observed this positive effect on myself and others.
It will be much easier to publish your code. You can publish your Web applications by running native CVS commands.
You do not have to leave your native development environment. You can make use of SAMBA, FTP, SSH, SFTP, or any other method to edit your code on your working copy, and any of a number of different methods (such as SSH described above) to transfer files between the CVS repository and your working copy.
CVS eliminates the need to divide tasks between developers by page and allows developers to work on any file without notifying others to not touch that file in the meantime.
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.