Continuus/CM vs. ClearCase We compare two tools that use very different approaches to controlling configuration management. Interestingly enough, both succeed. By Dave St. Clair

July  1995

In the growing Unix software configuration management market, two products usually make the short list for most users. These two complete products are quite different in their approach: Atria's ClearCase centers on version control while Continuus Software's Continuus/CM touts process control. This comparison highlights the strengths and weaknesses of each approach, and by extension, each product.

Mail this article to a friend

Since before the Unix epoch, the need to manage change when developing software has been essential to ensure quality and maintainability. It is nearly impossible to find a developer who does not have a definition of software configuration management (SCM) -- unfortunately no two definitions are the same.

To one developer, SCM implies formal, complex policies and procedures tied to approvals and productivity reports. Another developer may consider SCM to be a simple layer of shell, perl, or TCL scripts sitting on top of the old Unix standbys SCCS or RCS. (See Hal Stern's column this month, Bell letters, on using SCCS to maintain system files.)

In reality, SCM is either definition, or neither, or somewhere in between. Control is SCM's goal, with dominion over:

• Source file versions
• Configuration and delivery
• Process management
• Problem tracking

Seasoned Unix developers possess a good handle on version control. SCCS and RCS are simple, popular examples. Both keep deltas for each version of a file, and both maintain a modicum of check-in and check-out security. For small projects, SCCS/RCS may offer an acceptable SCM solution.

SCCS/RCS falls flat in configuration control, which implies a higher level of abstraction than version control. The SCM tool must have some knowledge of which versions from a set of components comprise a specific build. The developers behind SCCS and RCS left this control up to the developer or project leader.

Process management deals with the grouping and manipulation of software versions as they meander through the software life cycle. This typically involves change management, approval levels and production control.

Problem tracking entails recording enhancement requests or bug reports and correlating these with the resolution of the request. These reports may include a listing of the sources involved in the change. These change sets can then create released products containing only the feature and fixes desired.

By virtue of their diverse user requirements and wide range of features to support, the latest SCM tools vary in appearance and implementation. Two of the top SCM tool contenders, Continuus/CM from Continuus Software (formerly CaseWare) and ClearCase from Atria Software, illustrate this diversity.

Both are high-octane tools aimed at solving all facets of configuration management, but attack the problem in completely different ways. While ClearCase is a version-driven solution with user configurable hooks for process management and problem tracking, Continuus/CM is process-driven from the start and provides a complete software life cycle solution.

(By no means are these the only tools available to Unix users. We've got a list of more configuration management software. We also took a quick look at Tower Concept's Razor.)

What is ClearCase?
Like all SCM tools, the heart of ClearCase is a permanent, secure data repository. Traditional systems employ a vault system of storing files or objects. Developer work environments are created by extracting source file versions from a central database and placing them in a private work area. This work area is unique to a defined configuration. All enhancements and bug fixes are made in this work area which is outside of the tools control. Once the changes are made, the developer "checks in" the effected files.

ClearCase doesn't take the traditional approach: it uses a Multiversion File System (MVFS) to create virtual work areas for the developers that are completely within version control. The goal being to make the database appear as a local directory structure instead of a database. The developer can traverse the database with cd commands and browse with ls and cat.

The permanent data vault of ClearCase is termed a Versioned Object Base (VOB). The VOB contains data shared by all developers, including:

• Current and historical versions of source files
• Derived objects built from the sources by compilers, linkers, and others
• Detailed accounting information on the development process itself, such as who created a particular version or what versions of source went into a particular release.

There are many versions of objects in a VOB, and there may be many names and directory structures for the various files. It is not really useful to see all versions of all objects at the same time. To that end, users typically work with a view of the VOB. This makes the VOB look like an ordinary file system source tree. The view enables users to see the repository by selecting a single directory hierarchy and one version of each member file.

The view is intended to be where actual work takes place -- it is typically private for an individual developer but can be shared among users. It may also be restricted to a single machine or broadcasted to all or part of the network.

Each view has a user-defined configuration specification that consists of a set of rules for selecting versions of elements. These rules may specify the use of the latest and greatest version of each object or they may dictate the use of only the latest files of a given directory or it could specify the use of files based on some time stamp. Developers must be careful when entering these configuration specifications as it is possible to suppress objects from certain views if they don't match any of the rules.

Multiple views of the same objects do not necessitate multiple copies of the objects in each developer's workspace. In the case of fairly static objects, ClearCase keeps the physical storage of the object in the VOB -- it only exports references to the developer views. Also, views can share derived objects (libraries, object code) built from shared source files. This not only saves space but cuts compile time.

(We're offering a more detailed report on using ClearCase as well as sample screen shots.)

Continuus/CM
Continuus/CM's heart is the process management required to configure and manage software. The tool controls the flow of software throughout the development cycle from original/legacy software through testing, release, and maintenance.

Continuus/CM follows the traditional vault system with a twist. It employs a full functioning RDBMS engine (Informix) to manage the versioned objects and any associated data (owner, change dates, etc) while maintaining a solid object-oriented data structure.

Continuus/CM manages a repository of version objects in an object pool. This pool contains all versions of all objects. Continuus/CM maintains a single instance of each object regardless of the number of developers using a specific object version.

Each object has a type which encapsulates its data and behavior. Typical types are c sources, libraries, directories and executables. Descriptive information distinguishes each object type from other types and encapsulates its data and behavior. Each piece of information about an object is an attribute. Objects will have a source attribute which is the actual contents, many descriptive attributes such as owner, modify-time, and status and several procedural attributes (methods) which control editing, comparison, and printing. Most of these types have a parent type so that attributes and behavior may be easily inherited to create new types.

The highest level object is the project. A project represents an arbitrary collection of files, directories and even other projects. Projects are versioned like any other object.

There are two basic types of projects: working and prep. A working project is used by a developer to have one or more insulated work spaces to develop and unit test enhancements and bug fixes. Prep projects are used to prepare software for integration or system test or final release. A prep project represents all developers' work for a specific stage in the project's life.

Projects are not updated with the changes automatically. A manual reconfiguration is required (this can be done automatically but performance takes a huge hit). The objects brought into a specific project are subject to user-defined selection rules. The selection rules pick objects based on attributes such as owner, status and release. A developer could conceivably opt to use a previous version of a library while using the latest application code.

Working project can be reconfigured at the developer's discretion while prep projects are usually at the mercy of the project leader or manager.

Continuus LifeCycle
The majority of objects in Continuus/CM fall into the broad category of source. This would include source files, shell scripts, headers, makefiles, help files, and data files. A directory itself is a source file since a directory is simple a file containing a reference to other files (its members).

The default life cycle has source objects beginning in the "working" state and transitioning to the integrate, sqa, and released states:

• The working state is used for code development
• The integrate state is used for integration testing
• The sqa state is used for system-level testing
• The released state is for code made available for general use.

The transition of states is achieved by checking in the objects.

Continuus/CM has a role-based security system. Each authorized user has one or more roles which grants certain privileges. The most common role is developer. The developer can create and modify objects and test programs. The build_mgr is responsible for configuration and building of the prep projects for both testing and release. A developer can only promote an object to the integrate state; the build_mgr is responsible for further promotions. If a user has more than one role, it may be changed with minimal effort.

(We're offering a more detailed report on using Continuus/CM as well as Continuus/CM screen shots.)

Recommendations
Both Continuus/CM and ClearCase sell themselves as complete SCM tools and, indeed they are both excellent products. ClearCase provides a transparent solution for version and configuration management that has a definite appeal to most developers, but is rather weak in process management and problem tracking. The user can implement process management and problem tracking via triggers but this is a fairly large undertaking. One vendor, Pure Software, has addressed this shortcoming in its recently purchased QualTrak business by providing problem tracking with predefined triggers.

Continuus/CM, on the other hand, offers solid version and configuration control while supporting a flexible software life-cycle model. Throw in Continuus/PT for problem tracking and you get a complete SCM solution that can handle your development needs today and tomorrow.

About the author
Dave St.Clair (dave.st.clair@sunworld.com) is a software development project manager with Western Geophysical Exploration Products in Houston, TX. Reach Dave at dave.st.clair@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-07-1995/swol-07-cm.html
Last modified: