Printer Friendly Version

Imagine you are hours away from demonstrating your new perl e-commerce system for your client's CIO. Suddenly, you realize you've made a programming mistake that will break any code where someone types a single quote into a textbox: you forgot to escape them with perl's DBI quote function. You open the driver file to make the change, but without your knowledge, your colleague down the hall has the same file open, and he has finally figured out a bug that he's been working on all morning. A few minutes after you make your change, he saves over it. Unaware, you head to your demo.

The CIO types in his name to test the registration screen: "John O'Brien". The program crashes spectacularly with the dreaded "500 Internal Server Error."

"But I fixed that", you insist, red-faced, as your boss escorts you from the demo.
"I'm sure you did", she says, through gritted teeth. "But there isn't any evidence of that in the file, and the CIO thinks we're incompetent."

When you get back to your desk, you realize that not only was your change overwritten, but there is no way to recover your version.

Is such a scenario possible? In a multi-user environment without a version control system in place, it's not only possible, it's likely.

Version Control

The goal of a version control system is to make it easier and more reliable for more than one developer to work on a project without creating havoc. All version control systems have some features in common:

• A database that stores all the files for the project

• The ability to insert files into the database (add) and remove obsolete files (delete)

• The ability to modify a file safely (check-out), and the ability to add the modified file back to the database, creating a new current version (check-in). Most version control systems allow a comment describing the revision at check-in, as well.

• The ability to access older versions of code in case revisions need to be undone

• The ability to label versions so they can be referred to collectively

Migrating to a version control system does force a change in the way code is developed. It takes a little extra time to check-out a file, check it back in, and enter a comment instead of simply opening it up and coding. Also, version control can't replace communication between developers. That ebing said, if you have ever had a forehead-slapping "what was I thinking?" moment when developing a system, or worse, an "I'm going to kill my co-worker" moment, version control could be a solution.

CVS

CVS (the Concurrent Versions System) is a multi-user, open-source version control system downloadable from http://www.cvshome.org, which is available under the GNU license (free). It has been ported to almost every imaginable operating system. It is a multi-home environment, meaning each developer has his or her own working directory.

A sample CVS session might go as follows:
First, you want to open a group of files in the "myfiles" directory for writing:

   cvs -d ${CVSROOT} checkout myfiles

Once you have finished editing and testing your code, you are ready to add it back into the tree so the other developers on the project can see it as the new current version. You type:

   cd ~/myfiles
   cvs commit

Assuming there are no conflicts, the CVS editor (vi, notepad, etc., as defined in your environment variable) will ask you to enter a log message describing what you've changed.

Now let's say you want to commit your changes to multiple files. The release command will make sure that all your modifications are current. You type:

    cvs release -d myfiles
/*the -d switch deletes the working copy of the file */

but get the response

   M driver.pl

This response indicates that the file driver.pl has been modified since it was checked out, meaning that the version in your working directory does not match the master version. In order to find out what changed, you type:

   cvs diff driver.pl

At this time it is your responsibility to resolve the conflict, and once the conflict is resolved, you can commit and release the file.

If you are working on major changes to files and you don't want your in-progress code saved as the "master file" every day, but you want to keep up with the changes that other developers in your group are making to those files at the same time, you would type:

   cvs update

while you are in your working directory. This command merges the changes that have been made from the master file into your local copy only, so the only difference between your code and the master version is what you've written, and no one else can see your in-progress changes.

RCS

RCS (Revision Control System) is also available for Unix and PC systems under the GNU license from http://www.cs.purdue.edu/homes/trinkle/RCS/. It is also included with BSD-based distributions of Unix.

The chief difference between RCS and CVS is that RCS, the older software, is single-homed instead of multi-homed. Each developer does not have his or her own directory. Instead, there is one copy of the file. If one developer locks the file, another developer cannot check it out until the first developer has checked it in (an administrator can override the checkout if necessary).

In a complex, multi-developer environment, the inability of more than one developer to simultaneously open a file for writing can slow coding progress. However, in a smaller group, this issue becomes less pressing. The advantage of the single-homed approach is that the system itself is less complex—there will never be multiple revisions to merge. Other than this, RCS commands and functionality are similar to those of CVS.

A sample RCS session might go as follows:

First, the file must be created in the RCS system. You would type:

   ci driver.pl

and receive the response

   driver.pl,v  <--  driver.pl
   initial revision: 1.1
   enter description, terminated with ^D or '.':
   NOTE: This is NOT the log message!

Now, the program is asking for a brief description of the new file:

>> Drives the main logic for our e-commerce system.
>> .
done

At this point, the file is available for checking out in the future. To open it for writing, you would type:

   co -l driver.pl

and receive the acknowledgement

   driver.pl,v --> driver.pl
   revision 1.1 (locked)
done

If the file were already open for writing by someone else, you'd receive the error message:

   RCS/driver.pl,v --> driver.pl
   co error: revision 1.1 already locked by jsmith

At which point you'd have to call "jsmith" on the phone and find out whether he was actually editing the file or if he'd gone out to lunch, leaving it locked.

To compare your current modifications with the version you checked out originally, you'd use the command

   rcsdiff driver.pl

And to view the entire history, log messages, current locks, etc., for the file you'd type:

   rlog driver.pl

Finally, when you're done writing to the file, you would check the file back in using

   ci driver.pl

and entering a log message at the prompt. Now the file is available for writing by your colleagues.

In addition to the two version control systems described here, there are many other options (including expensive commercial ones) for controlling files in a multi-developer environment. More important than the tool you use, however, is the acknowledgement that any type of version control at all, while it may slightly crimp your style, will provide the valuable Five W's: Who, What, Where, When and Why (if a log message was entered) a code change was made.

The ability to track code changes by developer, time, and item; the ability to revert to previous versions of code; and the ability to preserve file integrity introduce a level of professionalism and accountability to the development process that is impossible without version control.