IT PASSION – "IT professional Blog"

Revision control concepts – Revision Control System (RCS), Concurrent Versions System (CVS) and Subversion

10 December, 2008 at 13:10 7 comments

Revision control (also known as version control (system) (VCS), source control or (source) code management (SCM)) is the management of multiple revisions of the same unit of information. It is most commonly used in engineering and software development to manage ongoing development of digital documents like application source code, art resources such as blueprints or electronic models, and other projects that may be worked on by a team of people. Changes to these documents are usually identified by incrementing an associated number or letter code, termed the “revision number”, “revision level”, or simply “revision” and associated historically with the person making the change. A simple form of revision control, for example, has the initial issue of a drawing assigned the revision number “1”. When the first change is made, the revision number is incremented to “2” and so on.

Version control systems are most commonly stand-alone applications, but revision control is also embedded in various types of software like word processors (e.g. Microsoft Word, OpenOffice.org Writer, KOffice, Pages, Google Docs), spreadsheets (e.g. OpenOffice.org Calc, Google Spreadsheets, Microsoft Excel), and in various content management systems. Integrated revision control is a key feature of wiki software packages such as MediaWiki, DokuWiki, TWiki, etc. In wikis, revision control allows for the ability to revert a page to a previous revision, which is critical for allowing editors to track each other’s edits, correct mistakes, and defend public wikis against vandalism and spam.

The Revision Control System (RCS) is a software implementation of revision control that automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, for example programs, documentation, procedural graphics, papers, and form letters. RCS is also capable of handling binary files, though with reduced efficiency and efficacy. Revisions are stored with the aid of the diff utility.

RCS was initially developed in the 1980s by Walter F. Tichy while he was at Purdue University as a free and more evolved alternative to the then-popular Source Code Control System (SCCS). It is now part of the GNU Project but is still maintained by Purdue University.

RCS operates only on single files, has no way of working with an entire project. Although it provides branching for individual files, the version syntax is cumbersome. Instead of using branches, many teams just use the built-in locking mechanism and work on a single head branch.

A simple system called CVS was developed capable of dealing with RCS files en masse, and this was the next natural step of evolution of this concept, as it “transcends but includes” elements of its predecessor. CVS was originally a set of scripts which used RCS programs to manage the files. It no longer does that, rather it operates directly on the files itself.

A later higher-level system PRCS^[1] uses RCS-like files but was never simply a wrapper. In contrast to CVS, PRCS improves the delta compression of the RCS files using Xdelta.

In single-user scenarios, such as server configuration files or automation scripts, RCS may still be the preferred revision control tool as it is simple and no central repository needs to be accessible for it to save revisions. This makes it a more reliable tool when the system is in dire maintenance conditions. Additionally, the saved backup files are easily visible to the administration so the operation is straightforward. However, there are no built-in tamper protection mechanisms (that is, users who can use the RCS tools to version a file also, by design, are able to directly manipulate the corresponding version control file) and this is leading some security conscious administrators to consider client/server version control systems that restrict users’ ability to alter the version control files.

Some wiki engines, including TWiki, use RCS for storing page revisions.

Basics of RCS

The Revision Control System (RCS) was designed by Walter Tichy of the Department of Computer Science at Purdue University. RCS is a software tool for UNIX systems which lets people working on the system control “multiple revisions of text … that is revised frequently, such as programs or documentation.” [TIC82] It can be applied to development situations of all sorts, including the creation of documents, drawings, forms, articles, and of course, source code.

In a typical software development environment, many developers will be engaged in work on one code base. If everyone was to be allowed to edit and modify any development item whenever they felt like it, it should be obvious that chaos would tend to result while little productive work got done. Instead of suffering under such an environment, most developers prefer to implement version control tools such as the one described here.

Version control tools allow an individual developer to maintain control over an item such as a source file while they implement and test changes to it. During this period, while the file is “checked out”, no one else is allowed to modify it. When the developer is satisfied that the changes have been implemented successfully and that they broke nothing in the meantime, the file may be “checked in” to the baseline database for use by everyone. The specifics of this process for RCS will be discussed in the tutorial proper.

Earlier implementations of version control tools include AT&T’s SCCS, IBM’s CLEAR/CASTER, and DEC’s CMS. RCS, implemented in 1982, attempts to fix several shortcomings the author found in previous tools.

What is CVS?

CVS is a version control system. Using it, you can record the history of your source files. For example, bugs sometimes creep in when software is modified, and you might not detect the bug until a long time after you make the modification. With CVS , you can easily retrieve old versions to see exactly which change caused the bug. This can sometimes be a big help.

You could, of course, save every version of every file you have ever created. This would, however, waste an enormous amount of disk space. CVS stores all the versions of a file in a single file in a clever way that only stores the differences between versions. CVS also helps you if you are part of a group of people working on the same project. It is all too easy to overwrite each other’s changes unless you are extremely careful. Some editors, like GNU Emacs, try to make sure that two people never modify the same file at the same time. Unfortunately, if someone is using another editor, that safeguard will not work. CVS solves this problem by insulating the different developers from each other. Every developer works in his own directory, and CVS merges the work when each developer is done. CVS started out as a bunch of shell scripts written by Dick Grune and posted to the newsgroup comp.sources.unix in the volume 6 release of July 1986. While no actual code from these shell scripts is present in the current version of CVS , many of the CVS conflict resolution algorithms come from them.

In April 1989, Brian Berliner designed and coded CVS . Jeff Polk later helped Brian with the design of the CVS module and vendor branch support.

Features

CVS uses a client-server architecture: a server stores the current version(s) of a project and its history, and clients connect to the server in order to “check out” a complete copy of the project, work on this copy and then later “check in” their changes. Typically, the client and server connect over a LAN or over the Internet, but client and server may both run on the same machine if CVS has the task of keeping track of the version history of a project with only local developers. The server software normally runs on Unix (although at least the CVSNT server supports various flavors of Microsoft Windows and Linux), while CVS clients may run on any major operating-system platform.

Several developers may work on the same project concurrently, each one editing files within their own “working copy” of the project, and sending (or checking in) their modifications to the server. To avoid the possibility of people stepping on each other’s toes, the server will only accept changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people’s changes on a regular basis. This task is mostly handled automatically by the CVS client, requiring manual intervention only when a conflict arises between a checked-in modification and the yet-unchecked local version of a file.

If the check-in operation succeeds, then the version numbers of all files involved automatically increment, and the CVS-server writes a user-supplied description line, the date and the author’s name to its log files. CVS can also run external, user-specified log processing scripts following each commit. These scripts are installed by an entry in CVS’s loginfo file, which can trigger email notification or convert the log data into a Web-based format.

Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project as of a given date or as of a revision number. Many open-source projects allow “anonymous read access”, a feature pioneered by OpenBSD. This means that clients may check out and compare versions with either a blank or simple published password (e.g., “anoncvs”); only the check-in of changes requires a personal account and password in these scenarios.

Clients can also use the “update” command in order to bring their local copies up-to-date with the newest version on the server. This eliminates the need for repeated downloading of the whole project.

CVS can also maintain different “branches” of a project. For instance, a released version of the software project may form one branch, used for bug fixes, while a version under current development, with major changes and new features, can form a separate branch.

CVS uses delta compression for efficient storage of different versions of the same file. The implementation favors files with many lines (usually text files) – in extreme cases the system may store individual copies of each version rather than deltas.

Distributed Concurrent Versions System

• any desired number of programmers concurrently developing an arbitrary number of development lines in workspaces isolated from each other
• worldwide and transparent distribution of repositories via secure connection; efficient replication and quick local server access for all operations
• integration in nearly all current GUIs and IDEs through the use of the default CVS protocol between the CVS clients and DCVS servers
• the functionality of snapshots replacing the more susceptible tags
• the functionality of change sets as powerful means for structuring code development and release/change management
• configurable e-mail notifications (add on)
• hooks for process control
• user control and authentication either by local system specific defaults or by distributed LDAP servers
• installation packages for all popular operation systems

Version Control with Subversion

Subversion is a free/open-source version control system. That is, Subversion manages files and directories over time. A tree of files is placed into a central repository. The repository is much like an ordinary file server, except that it remembers every change ever made to your files and directories. This allows you to recover older versions of your data, or examine the history of how your data changed. In this regard, many people think of a version control system as a sort of “time machine”.

Subversion can access its repository across networks, which allows it to be used by people on different computers. At some level, the ability for various people to modify and manage the same set of data from their respective locations fosters collaboration. Progress can occur more quickly without a single conduit through which all modifications must occur. And because the work is versioned, you need not fear that quality is the trade-off for losing that conduit—if some incorrect change is made to the data, just undo that change.

Some version control systems are also software configuration management (SCM) systems. These systems are specifically tailored to manage trees of source code, and have many features that are specific to software development—such as natively understanding programming languages, or supplying tools for building software. Subversion, however, is not one of these systems. It is a general system that can be used to manage any collection of files. For you, those files might be source code—for others, anything from grocery shopping lists to digital video mixdowns and beyond.

[wikipedia.org]
[http://ximbiot.com]
[http://tartarus.org/~simon]
[http://www.oreillynet.com/pub/a/oreilly/opensource/news/subversion_ch02.html]

Entry filed under: CVS, Revision control. Tags: Concurrent Versions System, CVS, DCVS, RCS, Revision control, Subversion, VCS.