IBM Rational Clearcase - An Introduction

ClearCase is one of the industry leading version control system from IBM. According to IBM following are some benefits of CleaCcase

Local and remote client access Flexible usage models: Unified Change Management (UCM) or base Rational ClearCase Wide range of supported environments including Windows, Linux, Unix and z/OS Transparent, real-time access to files and directories Support for disconnected usage Scales to support large geographically distributed enterprises Integration with leading IDEs including Eclipse, Rational Application Developer, Microsoft Visual Studio, and for systems environments the Cadence Design Framework II software Parallel development support including automatic branching and advanced merging and differencing technology Automated workspace management Integration with design, development, build, test and deployment tools

Compared to other version control systems like CVS or Subversion, learning curve for clearcase may be more steep. Initially we may feel like its very complicated and confusing, but after a period of usage, you can feel the real power of version controlling. Unlike Subversion, clearcase operations are not very stable and fail safe. At any point of time, it can break. But after gaining some experience, you will know how to fix things.

Clearcase Clients
IBM offers two kinds of clearcase client software. ClearCase Explorer (Fat Client) and Clearcase Remote Client (CCRC) (Thin Client). IBM also provides the client as plugins to popular IDEs like Eclipse and Visual Studio. In addition to these GUI clients, there is a comand line tool also available, which can be used to execute many commands which are not available on the GUI. Note: All the articles in this website are related to clearcase client usage for a developer/programmer. If you are looking for some clearcase server administration related stuff, this is not the place

Clearcase Basic Elements

Following is a brief explanation of various elements of clearcase. A basic knowledge of these elements are required to work with clearcase. Following is a diagram which shows a simplified structure of clearcase.

Logical Structure of Clearcase

PVOB (Project Versioned Object Base)

A PVOB is for storing the project details and the meta information about the project. It stores meta information such as project name, streams belong to the project etc. Basicall what ever

details you can see in "Clearcase Meta Data Explorer" is coming from the PVOB. See the below screenshot

VOB (Versioned Object Base)

A version object base is the physical location where all the project files will be stored. A VOB is actually a database. The database used by IBM to implement VOB is RDM Embedded database from Raima. In a typical clearcase server configuration, there will be many VOBs on different servers. You can find the VOB details from the PVOB properties. See below screenshot

Project
A clearcase project corresponds to your application project. Suppose 10 developers are working in a project, you may have 10 development streams and one integration stream inside the clearcase project (1 development stream per developer)

Project Folder
Project Folders are used to organize related projects. They may be many projects under a project folder

Streams (Development Streams and Integration Streams)

In simple words, a stream is a separate copy of all files in the project. Each stream has its own storage space and the files contained inside the stream is completely independent of files in other streams. Streams are generally divided into Development Streams and Integration Streams. There is no difference in the internals of Development Stream and Intgration Stream, just the name and the purpose it is used for, differs. Development stream is for the developer to develop the application. Integration stream is used to integrate code from different developers. In ideal

clearcase project configuration, there will be one development stream per developer and just one integration stream to integrate the work together.

Views (Snapshot View and Dynamic View)

So you are a developer and you have a development stream and all files inside the stream. Now we know that the stream is on the clearcase server (Remote Machine). To work on the files, you need to have a copy of the files in your local machine. This local copy of files is called a View. By defenition, a view provides access to resources inside a repository. Yo can see views in Clearcase navigator, see screenshot below

Views are of two types 1. Snapshot View and 2. Dynamic View

Snapshot Views
In a Snapshot View, clearcase copies all files from the stream in the server to a directory in your local machine. This directory is called "View Root". After copying files to local machine, you can disconnect from clearcase and start working on the files. Thats the main advantage of Snapshot Views; ie, Snapshot Views provides access to files even if there is no network connection to clearcase. After you complete your work, you need to store your modified files back to the server. This is achieved by doing the "Check-In" operation of clearcase. (After you do this your files will be safe on the server; even if your system crashes, your changes will not be lost)

Dynamic Views
In a dynamic view, there will not be a local copy of files in your local machine. But, you can see all files in the stream in your local machine (You can consider this as "Shortcut Links" to files on server. So the disadvantage of dynamic views is, you need network connection to access the files. But there is one advantage also with dynamic views. Since anybody modifies a file in dynamic view will be modifying directly on the server. So server copy of files will be always the latest copy. (In snapshot view server copy will become the latest copy only after you do "CheckIn" operation). Technically dynamic views are implemented using a proprietary network file system called MVFS (Multi Version File System). Using this file system, the VOB will be

mounted on to a network drive (windows) or part of the root file system (Unix/Linux). Dynamic views are something unique to clearcase; other version controlling softwares like subversion or CVS doesn't have a similar thing.

When to Use Snapshot View and When to Use Dynamic View

If you are a developer and want to do code changes, Snapshot View is for you. That is the main intention of snapshot view, allow disconnected access to files/resources. Usually when ever you join a clearcase project and start developing, you will be using Snapshot view only. Dynamic View is for special needs. Following are a few cases where dynamic view is more appropriate. 1. While creating a view from the Integration Stream 2. I can't think of any other scenario, where a dynamic view is more appropriate :-) Note: Why dynamic view is recommended for creating a view of Integration Stream? The reason is, to integrate each developers work, we always need to have the latest copy of files in the integration stream. Since dynamic view will always have the latest copy of files, it is most suited for views of integration streams

IBM Recommended Project Configuration in ClearCase

Per IBM every clearcase project can have one development stream per developer. The developer can then create one or more "views" from his stream. Also there can be an integration stream to integrate the work from different developers. Following are a few advantages of this configuration. In a typical IT project, every developer will be doing a specific set of functionality. Since every developer will have their own private copy of files, they can work independent of others. At the end of the day, even if the functional unit of code is not complete or the code has errors, still he can check-in all his code to his stream (In other configurations if you check-in code will errors, it will affect other developers). Another advantage would be, if somebody has done some nonsense and totally screwed up the stream, other developers won't be affected. (In other configurations, this will affect the productivity of the entire team)

Other Project Configurations

In some organizations, people prefer to have only one one development stream per project. Each developer then creates a view from the same stream and work on it. There will be one integration stream to integrate the work. In this configuration, the developer should check-in only completed functional units without errors, otherwise other developers will be getting your errors when they update the latest files in their view. In some other nonsense organizations, each developer create a view directly from the integration stream and work on the view. There will be no development stream. (Its more like renting an airplane for traveling half a kilometer)