ClearCase Branching

Branching allows developers to work in parallel. But before you embark on ClearCase branching, it is important to understand how it works. Learn more about ClearCase branching basics.

Base ClearCase vs. Unified Change Management

There are two different options when it comes to ClearCase. These options have key differences, especially when it comes to branching.

Base ClearCase

If your company is using base ClearCase, there is no real relationship between branches. The mainline and subsequent development branches are not related. Each file has its own independent representation of the branching structure. And no one file gives the complete picture of how things are related.

To compensate, companies usually implement a naming convention, outline the branching structure on a whiteboard, or write scripts on top. Without these workarounds, changes are almost impossible to properly propagate between branches.

Unified Change Management (UCM)

Unified Change Management (UCM) is a structured layer on top of ClearCase that provides some configuration management.

UCM IBM ClearCase is a stream based version control. Streams were designed to add structure to your local environment and assist in branching and merging. But due to the design, it can be very restrictive for teams and not adaptable to modern workflows. It also introduces an added level of complexity that is difficult for any developer.

In both systems, branches are individual attributes of a given element (file or directory). Although base ClearCase does not keep relationship information between branches, UCM does provide a view of the branches (streams) across all files. It manages the versions created on each stream.

ClearCase VOBs, Baselines, and Views

So how does ClearCase branching work? ClearCase has a file-based architecture. All elements (files and directories) and versioned independently.

ClearCase VOBs

All branches, streams, elements, components, objects, and metadata are stored in a Version Object Base (VOB) repository. When ClearCase first originated, it was designed to handle 1,000s of files with yearly releases. But now, projects are bigger than ever and are releasing much more frequently.

This leaves many companies with a large monolith VOB model that cannot scale to today’s demands. But splitting up a VOB is difficult when you are unsure how all the components are related. It can be difficult to untangle. For companies who implemented scripting, it would be too time-consuming to rewrite.

ClearCase Baselines

A UCM baseline is used to identify a version of every element or component in a project. Baselines are used to represent a particular stage of development. In base ClearCase, you would use labels to achieve the same functionality.

UCM baselines and base ClearCase labels are used to tie together a complete set of files for a release. But because of the structure, this is implemented by applying meta-data on a per file basis. This per file processing is complicated and difficult to scale as your project grows.

To help distinguish between baselines you can set a property to help indicate the quality level. For example, “passes initial testing.” But managing a bunch of baseline property tags, often with incomplete descriptions, is difficult. It leaves teams relying on a naming convention to determine the stability of a baseline.

ClearCase Views

In order to work on ClearCase branches and streams, developers use views. A view is essentially a work area. Each has its own config spec, which implements some guidelines for what files and baselines are available for development.

Views can either be “snapshot views” (local files) or “dynamic views”. Dynamic views use the Multi-Versioned File System (MVFS) to access data in real time. All operations are performed on a per file basis — one at a time.

With base ClearCase, end users are responsible for configuring the view’s config spec which can be very complex and error prone. Often, admins are required to manage it via manual processes or scripting. But doing this for a large company is costly to maintain. In UCM, you do not have to manipulate these views directly. When a developer creates a view in streams, it automatically generates the config spec so the developer can get access to the right files in the view.

ClearCase Branching Streams

There are different types of steams in ClearCase. These are implemented when you are managing multiple streams in development. These include:

• Integration streams
• Development streams

An integration stream collects the history of shared branches in a project. These usually contain the changes from multiple development streams where developers work in isolation.

Development streams need to have a hierarchy that is in line with your branching strategy. This can help you merge and integrate changes. But due to the lack of customized workflow options, teams are limited as to what they are able to do. UCM is unable to adapt to the many different branching patterns needed in modern software development.

Merging Changes in ClearCase

In ClearCase, integrating changes between team members can be a struggle. This is because in ClearCase, there is no true concept of unit of work. Merge operations are associated with “activities” which track the elements (files and directories) associated in that merge. However, as changes propagate, that relationship breaks down and developers loose that ability to track changes accordingly.

For example, you make changes to the GUI by editing several files as part of a new feature. The files are checked in, merged to the integration stream, and then to another stream along with other people’s changes. But there is no way of viewing these GUI changes as a group. Teams immediately lose traceability. Developers would need to do a lot of manual work to pick out what files where changed for a particular feature.

Because viewing and organizing these changes is so time-consuming, other processes can often be delayed. Integration and testing can take longer. Drawn-out code freezes can delay releases. This is because users are spending a lot of time fixing merge conflicts. Also, changes may need to be applied to several other versions. With both base ClearCase and UCM, there is no indication of changes should be propagated across branches.

Branch Smarter With Perforce Streams

Helix Core — version control from Perforce — also has Streams. But unlike ClearCase streams, Perforce provides automation for branching and merging. Streams logs relationships between branches, making it easier for developers to branch and merge. Plus, Streams is flexible enough to adapt to your branching strategy and is easily customizable.

Instead of complex scripts, release engineers always know what streams still need changes. Unlike ClearCase, Helix Core integrates with the tools release engineers need to keep your pipeline moving. Streams provides structure to support the complex branching and release models. And it is flexible enough to adapt to how your teams work.

How Perforce Streams Beats ClearCase Branching

In Helix Core, when a developer creates a branch, Streams sets up their workspace automatically. This is similar to a ClearCase view. But, Helix Core tracks not only what version of files a developer should have, it also tracks what versions they already have. This improves developer efficiency by eliminating investigative work.

In Helix Visual Client (P4V), developers can see which files are being worked on and by whom. And with permissions down to the file level, Helix Core can manage even complicated configurations, many of which are impossible in ClearCase.

Streams makes propagating changes easy. Everyone can visualize the flow of change.

With Perforce Streams, teams no longer need to rely on naming conventions, tags, and labels to support releases. This is built in. Forget about documenting branching strategies on a white board. Because with Streams, you always know where your code needs to go.

Remove the complexity and start using Perforce Streams.

TRY HELIX CORE FREE

Want to learn more? Explore version control branching.