The Network  
Network Search Sites Services ITcareers

Advertisement: Support Unix Insider, click here!

Home Home E-mail this article E-mail this article Printer-friendly version Printer-friendly version Tell us what you think Tell us what you think
put phrases in quotes
Spacer NAVIGATE Spacer
Spacer Subscribe -- It's Free Spacer
Spacer Topical Index Spacer
Spacer Back Issues Spacer
Spacer UnixWHERE Spacer
Spacer Events Calendar Spacer
Spacer Community Discussions
Spacer TECHNICAL FAQs Spacer
Spacer Solaris Security Spacer
Spacer Secure Programming Spacer
Spacer Performance Q&A; Spacer
Spacer SE Toolkit Spacer

Spacer Spacer
Spacer Spacer
Spacer Expert Advice Spacer
Spacer RFP Center Spacer
Spacer Training Center Spacer
Spacer Research Spacer
Spacer Vendor Content Spacer
Spacer Advertising Info Spacer
Spacer Unix Insider FAQ Spacer
Spacer Unix Insider Editors Spacer
Spacer Masthead Spacer
Spacer Editorial Calendar Spacer
Spacer Writers' Guidelines Spacer
Spacer Privacy Policy Spacer
Spacer Link to Us! Spacer
Spacer Copyright Spacer
Spacer BACK TO TOP Spacer

CVS in the scripting landscape

How to use CVS to monitor and manage code changes and improvements

October 1, 1999: CVS in the scripting language
Cameron and Kathryn discuss how CVS helps manage distributed development and use. (1,300 words)
October 15, 1999: Let the REBOLlion begin
How REBOL and other scripting languages are gaining industrial acceptance. (1,200 words)


By Cameron Laird and Kathryn Soraiz
In 1999, open source projects have become even more open. Not only can anyone receive an application's source code at version release, but it's now possible to keep up with its daily code changes. This installment of Regular Expressions is a tutorial on how you can use Concurrent Versions System (CVS) clients to monitor and manage fixes and enhancements. (You can also see Rich Morin's Silicon Carny column for his thoughts on CVS in the open source world.)

CVS's recent ascent
Peer review and collaboration have been important in computing from the beginning. We're not so far removed from the time when the most common distribution method was to drive card decks or nine-track tapes from one site to another. Just recently, though, software engineering's technical basis has made a dramatic transition to reliance on standard configuration management tools, and CVS in particular. You can join the party with a few quick lessons on the rudiments of CVS.

As its home page says, "CVS is the most popular version control system in the free software community, used by Netscape, *BSD, many Linux projects, and others." You know how popular it is to argue the merits of Emacs versus those of vi, or token-ring versus Ethernet, or SCSI versus IDE versus SAN -- pick any territorial fight that spins your propeller. Just a couple of years ago, it seemed equally urgent to fuss over the change models underlying RCS (Revision Control System) and SCCS (Source Code Control System). That battle's over now, though: CVS (which is built over RCS) won. SCCS and pre-CVS RCS interest mostly historians. Until recently, a fair amount of programmer overhead went into fretting about which version control system to use, or whether to use one at all. With standardization on CVS, all that energy has been liberated to more productive uses.

CVS is a product of Cyclic Software, itself a recent acquisition of the SourceGear Corporation. Cyclic makes the source to CVS available under the GNU Public License (GPL). CVS works most everywhere you want it to: Unixes, Windows, Mac OS, OpenVMS, AmigaOS, BeOS, OS/2, and so on.

CVS comes in two major flavors, local and networked. This column concentrates on the networked version; sometimes, you'll see this called remote CVS, NetCVS, or client/server CVS.

Structural changes
CVS has a greater significance than the bare technical retrieval of the latest source. It's not just that there's widespread recognition that CVS is a handy mechanism for version control; it carries with it an entire collection of social conventions. A year ago, many open source projects regarded too much openness as hazardous. Insiders carefully polished source code before letting the public at large see their work. In the brief span of time since, there's been a mass migration from the cathedral to the bazaar, and the majority of projects now seem comfortable with all the transparency they can get.

CVS is both the technical means to facilitate this and a symbol of the fashion. There's no necessary relation between CVS and openness, of course. In fact, many commercial products also use CVS, and one area of exploration now is how to make source code available, but with restrictions -- only to those who have paid for a license, for example.

The impact of CVS has the potential to be greatest in what we often regard as the peripheral parts of a project. Software engineers know, at least in principle, how to run a project well enough to achieve code that works at least crudely. Every open source project, though, is behind in documentation, example uses, and testing -- every single one of them. CVS might be part of the technical fix that encourages better collaboration in these areas. This winter, we plan to report on new business models likely to emerge in this area. Particularly exciting are ideas from interviews we've done with Bruce Epstein, principal of Zeus Productions, and Tim O'Reilly of O'Reilly and Associates.

Our conclusion is that CVS is valuable for everyone working with software, whatever their mix of open source and commercial tools.

CVS among the scripters
We're running this introduction to CVS in Regular Expressions because the most prominent scripting projects now rely on CVS. This wasn't true a year ago. The transition was a nervous one for several people ("Will users criticize our daily maintenance work, and make nuisances of themselves?" was the sort of uncertainty afoot). The results have been at least as good as expected, though. Jeffrey Hobbs, Tcl ambassador at the Scriptics Corporation, told us:

NetCVS has brought the Tcl community closer to the core development. Users have been able to spot problems before we have had to go through a full release cycle. It also allows users to obtain fixes that are important to them without requiring them to wait for the next patch release.

But enough advertising. You should experience CVS for yourself. To do so, download a networked CVS client (version 1.09 or later of the standard distribution will work fine), and install it on your desktop. Move to a temporary, or working, directory. Suppose you have an interest in JPL, the Java-tized version of Perl that compiles Perl source into Java bytecodes (or will -- it's still a work-in-progress as of October 1999).

Then run these commands (or their equivalents, if you're not operating with a sh-compatible Unix shell):
     export CVSROOT

     cvs login
     cvs checkout jpl        

When the cvs login command requests a password, use a blank one. You want to construct copies of the latest JPL source tree underneath your working directory. That's all it takes to start with CVS.

To do more with CVS, read one of the several tutorials available online. We particularly recommend Jim Blandy's tutorial (see the Resources section below for details); Blandy is the Guile leader interviewed for our November 1998 column, and a cofounder of Cyclic. Among the commands you'll learn first are those that allow you to interrogate a CVS server about the projects it exposes, report on any changes between the current state of the central repository and your local working version, and prepare patches for specific source updates. For example, if you request cvs checkout -c against the central CVS repository for Tcl projects, you'll receive a list of more than three dozen distinct source trees you can examine, including Tcl/tk, incrTcl, and tclhttpd, with several branches available for each.

The flip side of CVS and scripting languages
So far, we've presented scripting languages as CVS "customers": CVS is part of the infrastructure for maintaining scripting language projects. That's not the only connection between CVS and scripting, though. Scripting languages also can serve and manage CVS operations.

The standard CVS distribution is coded in C, and CVS automations have traditionally been Unix shell scripts that interact at the command-line level. Programmers who've wanted more sophisticated control have already created both client- and server-side modules that allow CVS operations to be written in Java, Perl, Python, Tcl, and other languages. If your ambitions with CVS are bigger than the core application will support, you'll find it easy to customize your own GUI or Web interface with a few lines of your favorite scripting language.

In summary
It's time to educate yourself about CVS. Whether you're using an open source or proprietary scripting language, chances are that its core sources are maintained in a CVS repository, or will be soon. An hour or two installing a basic CVS client and practicing its use will give you access to the latest fixes for the languages and other technologies on which you depend.

To help you navigate the CVS world, we've prepared an index to public servers likely to interest scripters. See the Resources section below for a pointer to this and other introductory material on CVS.

See the Resources section for related links.

Page 1 of 2, continued...

Page 1.
Page 2. October 15: Let the REBOLlion begin
Printer-friendly (all-in-one) version

Home | Mail this Story | Printer-Friendly Version | Comment on this Story | Resources and Related Links

Advertisement: Support Unix Insider, click here!

Resources and Related Links
  Additional Unix Insider resources  

Tell Us What You Thought of This Story
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough

(c) Copyright 1999 Web Publishing Inc., and IDG Communication company

If you have technical problems with this magazine, contact

Last modified: Friday, February 09, 2001