Comparing concepts between ClearCase UCM and RTC

Daniel C. Toczala, IBM Jazz Jumpstart team
Last updated: September 10, 2010
Build basis: Rational Team Concert 2.0

Introduction

There seems to be some confusion about the differences and similarities between Rational ClearCase and Rational Team Concert.  Some of this is due to changes in terminology, and some of this is due to the different usage models and capabilities of the products.  This article seeks to clear up some of that confusion.

I include UCM as part of this discussion, since so many of our customers have deployed ClearCase with UCM.  If you are using ClearCase UCM integrated with ClearQuest, then I strongly suggest that you also read Comparing concepts between ClearQuest and RTC.

Basic Terminology

Let’s take a look at the differences between ClearCase UCM and Rational Team Concert (RTC).  ClearCase is a configuration management system. Customers may use it stand alone, or they may use the UCM functionality.  UCM forces users to create software Components, and then creates Baselines on those components. Files being modified are Checked Out, modified, and then Checked In within the context of a View, which is a work area for development.  Change Sets are built up with each of the individual changes made as part of an Activity.  These Change Sets are then shared with other team members through the Delivery of those Change Sets.  ClearCase stores it’s artifacts in a proprietary format, and stores all of it’s data in repositories called VOBs. Each VOB may contain one or more UCM Components. The individual VOBs can store artifacts in any directory structure that a user would like to use. ClearCase supports parallel development, and when there are conflicts between versions of the same file, these are resolved using Merges. In base ClearCase, VOBs may contain Branches, which are logical “splits” of the code to enable parallel development activities to take place in isolation. In UCM these Branches have some more formal constraints, and are referred to as UCM Streams. So a team member will Deliver his or her changes from their own working area, called a View, to a Stream.  Other team members will Rebase their Stream, and pick up changes made on the parent Stream. 

ClearCase has a concept of a Dynamic View, which is a workspace that changes without any user intervention, based on user configured settings. ClearCase also has the concept of a Snapshot View, which is a copy based workspace, associated with the state of the repository at a point in time. Snapshot Views are brought “current” by Updating the view. From either view type, Baselines and Change Sets may be Delivered from Stream to Stream, with any individual file Merges being detected by the system, and then resolved by the user. As Components get Change Sets applied to them, the individual Components will have Baselines (essentially a label across all artifacts within the Component or VOB) applied to them. A “master baseline” with a collection of Baselines across multiple Components is called a Composite Baseline.

In RTC SCM there are many of the same concepts, but there are some subtle changes. Jazz has a single repository, which stores its artifacts as REST-enabled resources. These resources are stored in a database. Jazz supports the use of many enterprise database technologies, including Oracle, DB2, and SQL Server. This is commonly referred to as the Jazz Repository. In Jazz, software is broken into software Components. These Components may contain artifacts in any type of directory structure, and parallel development is supported by use of Jazz Streams. Users working on Jazz Components will join a project, and will create their own Repository Workspace (which holds copies of all of their Change Sets), as well as a personal Sandbox work area on their local machine. As files are modified, the Jazz client will track those changes, and the user will Check In their changes. There is no concept of check out, although Jazz does support resource Locking. When a user sees changes in his or her Sandbox, they will Check In the changes, and relate them to a Change Set, which collects the individual changes and stores them in the Repository Workspace area. These Change Sets can then be Delivered to one or more Jazz Streams. Other team members will Accept changes to their Repository Workspace from this Stream, and pick up changes made on the parent Stream.

The user Sandbox, or Eclipse Workspace, can have its status checked at any time, with the interface indicating all potential outgoing Change Sets (work the user wants to Deliver), as well as incoming Change Sets (work done by other team members). Users are able to select Change Sets to either Deliver (sharing their Change Sets with the team), or Accept (applying Change Sets in the Stream to their own Repository Workspace and Sandbox), on an individual basis. Baselines of the Components can also be created, and a collection of Baselines across multiple Components is called a Snapshot. This should not be confused with a Snapshot View in ClearCase, as the concepts are completely different.

There are a number of subtle differences in the way that these systems work, and it gets reflected in how users will interact with these systems. In ClearCase, users are often encouraged to create Streams and Branches to isolate their work. Often customers will create multiple Views (workspaces), with one set of changes being done in each View. This is done so changes can be isolated from each other, and to ensure that no artificial dependencies are created between Change Sets. In Jazz, users are encouraged to perform one change at a time within their Sandbox (workspace). Users working on multiple changes have a choice, they will either create multiple Sandbox and Repository Workspaces, or they will Suspend work on one Change Set, before beginning on another one. This ability to Suspend work essentially takes all of the changes associated with a Change Set, and stores them in the Repository, so a user can Resume (or reapply) these changes at a later time. The Workspace is then returned to the state that it was in prior to the changes from the Change Set being applied. This helps cut down on the number of Workspaces that developers must keep track of.

When using ClearCase with ClearQuest and UCM, it is possible to associate a ClearQuest Record with a Change Set. This requires some configuration, and availability of both the ClearCase repositories (VOBs), and the CQ database. In Jazz/RTC, all of this information is in the same Repository, so a link is created between the Work Item and the Change Set. Since everything is REST-based, many different types of Jazz objects can be linked to each other, providing greater flexibility in the relationships between development artifacts.

For more information

• Basic SCM functionality – a quick over view of the basic SCM functionality
  
• Confessions of a new Jazz developer, Part 2: Getting things done – a nice “day in the life of a developer” use case, with RTC and Jazz
  
• Implementing the “Remote Development Line” pattern using Jazz SCM – an older article on supporting geographically dispersed development efforts with Jazz SCM
  
• Working on the SCM Command Line – link to the SCM command line documentation.
  
• Jazz Administration Guide
  
• Jazz Deployment Guide

About the author

Daniel Toczala is the Technical lead of the Jazz Jumpstart team.  He has worked with Rational Services in the past as a Senior Solutions Architect.  He used his experience in helping a variety of customers in implementing organizational change to help build the concept of deployment patterns.  He has done numerous presentations on how organizations can utilize Jazz technologies and Agile approaches to software development to improve the value that software development organizations deliver to their customers.
Dan travels the world helping IBM customer, but his home is in New Hartford, NY.  He can be contacted at dtoczala@us.ibm.com.

Feedback

Was this information helpful? Yes No 29 people rated this as helpful.

Let us know how we can improve this information.