Why You need to have a Cutting Edge SCM Tool for your Development Team and move away from old ones

Before Modern SCM tools came to existence, there used to be (and still is) a tool called Clearcase which was developed in 1992 by Atria Software, and came to IBM after a series of Aquisitions and now being "modernised" by HCL Software

It is one of many version control systems available today, like GIT, SVN , TFS etc

ClearCase Basics: How It Works

Lets see what Clearcase is and how its designed and how it works

File-Based Architecture

ClearCase has a file-based architecture. All “elements” (files and directories) are versioned independently. The directory structure is managed in a similar fashion to a Unix filesystem.

ClearCase elements are stored in repositories called Versioned Object Bases (VOBs). Users access these elements using a “view”. A view can either be a “snapshot view” (local files) or “dynamic view”. Dynamic views use the Multi-Versioned File System (MVFS) to access data within a VOB in real time.

All operations are performed on a per file basis — one at a time. Here’s an example:

If you wanted to “tag” and entire build or release, you would need to apply the tag recursively to each file and directory. One at a time. This is a tedious and time-consuming task. And it only gets worse when the number of files increases.

It is impossible to group changes to multiple files into a single database transaction. (It is not atomic.) This dramatically increases the potential for partial delivery of bug fixes and features. As a result, broken builds become far too common.

ClearCase was designed back in an era of where projects consisted of 1,000s of files, yearly release cycles, and file sharing over a LAN.

This has created some complications in the modern era of 100s of 1,000s to millions of files, weekly and daily release cycles, and file sharing over the WAN.

Monolithic Codebases

Teams that are still using ClearCase more than likely have monolithic codebases. (Monolothic codebases are ones where all code is in one massive logical codebase.) But ClearCase has scalability limitations. So, these monoliths are often split physically into multiple VOBs.

Monoliths contain all of your legacy code and full version history. However, it gets increasingly more difficult to maintain the code in a monolith over time.?That slows down velocity. And it compromises quality, while putting your business at a competitive risk.

Replication Model: ClearCase MultiSite

ClearCase requires an add-on for replication —?ClearCase MultiSite.

ClearCase MultiSite enables developers at different locations to use the same VOB. However, ClearCase MultiSite comes with a price —?and a steep one at that.

If you replicate a repository for the person who needs it, you’ll have to pay for everyone who touches it. (Even if you have 100s or 1,000s of developers locally —?and only 5 people remote!)

You have to continually manage the “branch mastership” in ClearCase MultiSite. This adds a lot of overhead to the development teams, reducing velocity.

Branching

ClearCase branching is done on a per-file basis. When merging from branch-to-branch, you still merge on a per-file basis. ClearCase UCM (Unified Change Management) is a layer on top of ClearCase. UCM manages branching and merging in a restricted way. But under the covers, everything still happens on a per-file level.

Most teams using ClearCase fit into the following types:

• They use no branching or little branching.
• They do some branching manually, typically with private, task, or feature branches.
• They do extensive branching and manage it with scripting.
• They are using UCM and dealing with the constraints and performance issues that come with it.

ClearCase branching and merging used to make for effective collaboration. However, as software and hardware projects have grown in complexity, ClearCase hasn’t been able to keep up. This results in slow performance and difficulty branching and merging at scale.

Security & Audit Controls

ClearCase permissions are enforced at the file/directory level. They follow a model very similar to the Unix filesystem.

ClearCase permissions ensure that no one accesses the repositories without appropriate credentials. These permissions are defined at both the VOB level and the element level. Any changes a user makes are transcribed and maintained for traceability. Plus, admins can use scripts to enforce policies on a shared repository.

However, ClearCase permissions are tied to the OS. This makes it difficult to manage complex rules and proper sync permissions across multiple platforms (e.g., Windows, Linux, Mac).

Admin Required

Typical enterprises require a team of admins to set up and maintain ClearCase. The number of admins required increases when ClearCase MultiSite is also in use. Due to ClearCase’s chatty communication and resource intensive nature, the hardware requirements are also quite costly.

It takes a tremendous amount of resources to:

• Configure the ClearCase servers.
• Manage interop environments (mixed Windows and Unix).
• Orchestrate a backup solution (there is no native way to do a hot backup).
• Manage the complexities of MultiSite.
• Deal with client side installations.

Is ClearCase Dead??

ClearCase isn’t totally dead yet. Many teams still use it. But ClearCase’s popularity is dying.

At one time, ClearCase was at the cutting edge of technology. Today, however, some of ClearCase’s technology can actually slow down development teams.

5 Risks of Using ClearCase (and ClearCase MultiSite)

Here are some of the biggest risks facing teams who continue to use ClearCase.

1. Lack of Support

ClearCase is now supported by HCL, as part of HCL’s 2016 partnership with IBM. But support is lacking. This has raised concern among many teams using ClearCase.

2. Lack of Meaningful Updates

ClearCase hasn’t changed much in recent years. IBM is still developing and maintaining it. But recent releases have lacked new, modern features that most teams seek. As a result, ClearCase hasn’t kept pace with trends in the industry.

3. Slow Performance

ClearCase has notoriously slow performance. This is especially true as the number of assets grow —?and as large monoliths become even larger. Simple operations like updating or merging can take minutes to hours. This has a big impact on developer productivity (and patience).

4. Painful Replication

ClearCase offers replication (with ClearCase MultiSite) —?but it’s painful and expensive. License and hardware costs to implement ClearCase MultiSite are high. Maintenance of “oplogs” and “epoch tables” require dedicated administrative resources. The branch mastership model of replication requires development teams to add extra steps to collaborate —?thus slowing velocity.

5. Complicated Branching

ClearCase branching is complicated — and creates problems for teams. For starters, there’s no defined relationship between branches and no associated workflow for the development process. And there’s no built-in method to identify which fixes need to be applied across several different branches, increasing the risk of regressions.

=====================================

Alteratives to Clearcase

Consider moving to git based SCM, along with Enterprise Addons like GitLab, GitHub, BitBucket etc

What ClearCase and Git Have in Common

Both of them are used for version control. And both have the ability to branch and merge. But that’s where the similarities end.

ClearCase vs. Git: 7 Key Differences

ClearCase and Git are entirely different breeds of version control. There are 7 key differences you’ll need to consider when choosing between them.

1. Architecture

Architecture is the biggest difference between ClearCase and Git. ClearCase is centralized while Git is distributed.

ClearCase has a file-based architecture (where everything happens at the file level). And Git has a hash-based architecture (where everything happens at the branch level).

In ClearCase, you need to apply metadata (e.g., tags) for every file — one at a time. That’s all well and good —?if you have 10 files. But when you have 100K or more files, applying those tags manually just doesn’t fly. You’ll need to create an entry for every single file. If someone tries to pull all files with that tag?while you’re still tagging, it can break builds and wreak havoc.

The same work of creating a label in Git might only take a second.?

Which One Has Better Performance?

It depends on who you ask.

Git has better performance at an end user level. Developers like the distributed and decentralized nature of Git, where everyone can clone from everyone. And they can do their work without being connected (including diffs, merges, rebases, etc.).

However, Git’s architecture creates problems at an enterprise level. Enterprises need a single source of truth. Git can’t provide that (unless you add tools like Bitbucket, GitHub, or GitLab).

ClearCase can provide a source of truth at an enterprise level. However, it creates performance bottlenecks and can break builds. It was built for an era of 1,000s of files. Not an era with 100K to millions of files. And the larger the number of assets, the slower the system.

There’s a lot of work required to view a single file. And ClearCase is also network-intensive.

2. Repository Design

Repository design is another area of division for ClearCase and Git.

ClearCase repositories are Versioned Object Bases (VOBs). While a team might have multiple large VOBs, they’re all considered part of a monolithic codebase. The same volume of files (typically used in ClearCase) would require exponentially many repositories in Git.

This difference in repository design is related to a bigger version control issue. Is it better to have a monorepo or multiple repos?

There are a lot of benefits to using a monorepo. For starters, a monorepo provides a single source of truth for your team. This makes it easier to share and reuse code —?and collaborate across teams. It also simplifies dependency management. Plus, you’ll be able to make atomic changes across the whole project.

Multiple repositories are most often used if you need to break up files based on type of file or team. By componentizing your repositories, it helps you solve some scalability issues. But you’ll still struggle to stitch everything back together and get a single source of truth. And you won’t be able to atomically submit changes.

Which Design Scales Better?

ClearCase’s repository design scales better than Git’s. That’s because a monolithic repository is simpler, clearer, and atomic.

Splitting?GIT into multiple repositories?might make it easier to manage the individual pieces. But it’s more difficult to manage the whole project.

Scale and Still Work With Git

It’s time to switch to a better version control. One that scales. One that’s fast. One that gives you the automation, flexibility, and control you need for branching. One that works with Git.?

3. Branching and Merging

Git and ClearCase have major differences in branching and merging

Git offers lightweight branching, which can be faster. ClearCase, on the other hand, offers more granular merging.

Git branching is an instantaneous process. You merge from branch to branch.

ClearCase branching is done on a per-file basis. When merging from branch to branch, you still merge on a per-file basis.

Both Git and ClearCase have good merge algorithms.

Which Branching/Merging Model Is More Efficient?

Git’s lightweight branching is more efficient.

But there are still issues with the Git branching model, particularly if you’re working in a large repo. For instance, if you have 100 files that are different, you need to merge all 100 of those files. You can’t just merge a couple of files and be done.

ClearCase branching involves a lot of manual effort. It’s time-consuming. And it makes working on private/task/feature branches more painful for ClearCase developers. On the other hand…

ClearCase merging is more efficient.

In ClearCase, you can do a merge preview. And then you can divvy up the work and merge by file. However, merge conflicts can be time-consuming in ClearCase.

Git merges can run into some issues, particularly if you have multiple teams working in the same repository. You wouldn’t be able to divvy up the work, like with ClearCase. For instance, if you have different assets in Git repos —?e.g., PHP code and C++ code — a PHP developer could be asked to merge C++ code.

4. Replication Model

The replication model is another important factor to consider with ClearCase vs. Git.

ClearCase offers a separate product for replication, at an additional cost — ClearCase MultiSite. Git doesn’t have a replication model —?you’ll need to add a product such as Helix4Git, Gerrit, or GitLab Geo.

Replication is an absolute necessity for teams with remote users. It allows them to experience local performance, despite being remote.

Which Replication Model Is Better?

There are issues with both replication models.

ClearCase Multisite is an expensive add-on. If you replicate a repository for the one person across the globe who needs it, you’ll have to pay for everyone who touches it (even if you have 100s of developers locally). Managing and maintaining ClearCase MultiSite can be a nightmare, too.

Git, on the other hand, doesn’t have a native replication system. So, you have to choose between products such as Helix4Git, Gerrit, or GitLab Geo.

5. Usability

There are also key differences in usability between ClearCase and Git.

ClearCase has more overhead and is more difficult to maintain. Git can be faster to set up, but it’s missing a lot of key features.

ClearCase has much more overhead than Git. It requires expensive administration. There are specific (and somewhat ridiculous) hardware requirements. And it’s brutal to set up in interop environments (including a restrictive server topology). Git is simpler to setup and maintain.

ClearCase is also harder to use and can be slow. Developers see Git as faster than ClearCase. However, simplicity comes with limits. Git doesn’t natively offer everything that ClearCase can do. To switch to Git, you’d be giving up a lot.

Which Is Easier to Use?

Overall, Git is easier to use and maintain. But that comes at a price…

6. Security

There is a vast difference in security between ClearCase and Git.

ClearCase has granular permissions and can support compliance needs. Git natively lacks security features and requires additional tools.

ClearCase’s permission structure ensures that no one accesses the repositories without appropriate credentials. Permissions are defined at the VOB level. Any changes a user makes are transcribed and maintained for traceability. Plus, admins can use scripts to enforce policies on a shared repository.

Git has no security features in its native form. Using tools such as Helix TeamHub, Bitbucket, GitHub, and GitLab add layers of security. This includes granular permissions, user management, and authentication measures.

Which Is More Secure?

ClearCase is natively more secure than Git. But you can improve?Git Security?by adding tools.

7. Cost and Availability

There is a major cost and availability difference between Git and ClearCase.?

Git is free open source software, but it probably will require proprietary add-ons that come at an additional cost. ClearCase is only proprietary — and it’s expensive.

git is free. But free isn’t always free. To use Git, you’ll either have to write tools on top or buy front-end tools( Bitbucket, GitHub, or GitLab).

ClearCase is expensive to license, use, and maintain. It also racks up costs in developer productivity, since it is difficult to use.