Easing Web Application Development with CVS
Pages: 1, 2
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 updateto 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 commitand 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:
- Concurrent Versions System Home Page
- Official CVS Manual (a.k.a Cederqvist)
- Open Source Development with CVS
Setting up CVS with SSH Access on Windows:
- With WinCVS and Putty's "plink"
- Various setups from Apache.org
- SourceForge Tutorial on the subject
- Info from WinCVS.org
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.