Why use ClearCase when Git is “free”

A Source Code Management (SCM) tool is one of the most critical pieces of any software development organization’s tool suite. Selection, use, and potentially migration decisions can be “make or break” for some organizations. In some cases, the tool’s users may seem almost religious in their zeal for or against a given toolset. GIT is a currently-very-popular SCM solution created by the Linux Kernel team for their own use, and it has seen wide adoption. “Why aren’t we using GIT?” is an increasingly common question in organizations using proprietary SCM solutions such as ClearCase. This is particularly true when those organizations are looking to reduce costs.
​

​Git and ClearCase have radically differing architectures based on their design requirements and anticipated usage. Git is a radically-decentralized, radically-open, tool. ClearCase is a hybrid central/distributed SCM tool when paired with ClearCase MultiSite. Each of these architectures brings its own strengths and potential weaknesses, depending on the organization, or part of the organization, that uses the tools. It is not necessarily true that any one tool will serve all an organization’s needs, and it is not uncommon for a single organization to have multiple SCM systems in use. The challenge is selecting the right tools for the right use cases. This document will compare GIT and ClearCase to assist in evaluating which tool is best for a given part of an organization. 

In short(?): 
GIT’s openness makes it ideal for completely-open development by small teams, or small sub-teams. This very much describes the Linux Kernel project, each sub-team maintains its own “master” GIT repository, managed by the “maintainer”, who pulls changes from or ok’s user pushes to, this repository. This person in turn then notifies the main kernel maintainer – originally Linus Torvalds – that there are approved changes to bring into the main kernel release. The “maintainer” is also expected to ensure that updates from the “upstream” repository are applied to the sub-team’s master repository. All development work is completely transparent to all other users, and no “access control” needs to be applied. 

In contrast, ClearCase is significantly less “open” by design. From its inception, it was designed around the needs of Enterprise-level software development organizations who had to manage large complex codebases, and restrict access to those codebases to specific developer communities. Every ClearCase repository operation has multiple access checks, every attempt to access a given version of a file has access checks at the application and the operating system levels.  These versions are maintained in one or more shared repositories, with central access and policy control. 

Git’s strengths:  

• No acquisition costs or maintenance costs. GIT is provided as part of all mainstream Linux distributions and freely available for download for almost every other mainstream operating system.  
• Completely-distributed design allows for completely-disconnected development. Even the most isolated users to have full access to the project once they have created their local copy of the repository.  
• Open source nature gives lots of options: many platform options, many GUI options, and many hosting options. The freely available source code and porting guidelines allow for porting to almost any conceivable platform, including platforms as obscure and discontinued as AmigaOS (https://github.com/sba1/simplegit).  
• Selective “replication” of individual changes (commits) to remote repositories through “push” and “pull” operations speeds collaboration and code review with remote users, as well as saves bandwidth. 

• Simpler than ClearCase. Simplicity is relative. If GIT were “simple,” there would be no need for the dozens of books on using GIT, or the thousands of consulting organizations that advertise GIT expertise. ClearCase simply has more “built in” capabilities that are not present in GIT “out of the box,” thus there is less to learn for GIT than ClearCase. 
• Default SCM integration for many non-Microsoft IDE’s. 
• Services like GitHub are introduced in introductory-level computer science classes, this ubiquity means that newly hired developers are likely to be at least passingly familiar with GIT.  
  
  

Git’s weaknesses: 

• FOSS products do not have “post-sales” support. For critical issues, web-based forums may be inadequate. Third-party experts need to be hired, or high-level expertise needs to be developed internally. In extreme cases, this may include dedicating one or more developers to making changes to GIT source code.  

• Plethora of options can lead to confusion when “I know GIT” turns out to mean “I used this GIT GUI, and not any of the other dozen.” Familiarity with git as used in one organization may not translate to another organization of different integrated tools or GUI components are used. 
• Lacks significant workspace management. Each “workspace” is in fact a complete copy of the entire project repository. This can lead to issues if multiple releases of the same project are used in parallel. This is partially mitigated by “stashing,” but is borderline user hostile. 
• Copying all significant project history to all developer systems increases the importance of securing developer endpoints. Endpoint backups and disk encryption become critically important. 
• Complex projects that need multiple components from multiple repositories require use of GIT “submodules,” which are not very mature. 
• Disk space consumption can be extreme when dealing with large projects as git maintains the entire project history on each end-user machine. 

• Selective replication means that there is really no one “master” copy of the project with all change history. This raises a potential audit or compliance issue in heavily regulated industries.  
• Policy enforcement through GIT hooks needs to be applied by end users to their copy of the repository after creating it. This effectively makes policy enforcement “optional” unless the central administration team creates the repositories for the end-users. 
• Commit naming convention is based on an SHA hash. Unless the commits are labeled (an optional process) there is no simple at-a-glance mechanism to determine the relationship between 2 commits. This can be important when the question is “Did ‘these’ changes get into ‘that’ release?”    

ClearCase’s Strengths: 

• Mature product. FOSS products tend to have a larger change churn, meaning features may be deprecated or obsoleted at any given time.  
• Robust developer workspace management.  

          - Creating a new developer workspace using “dynamic” or “automatic” views can take      
       minutes as no data needs to be copied locally. Non-dynamic view types can be configured           to load as little or as much of project files as needed instead of GIT’s “all or nothing” approach. 
         - Using multiple component repositories is dramatically simpler than doing so with GIT. 
         - Parallel development of multiple releases of the same product requires creation of multiple “views” instead of multiple copies of the repository or use of “stashing”. 

• Centralized, or semi-centralized repositories improves security as the complete history of product components is not distributed to all developer hosts. 
• Centralized repositories allow for more robust policy and process enforcement. Policies set by administrators are not “optional.”  
• Robust access controls can be set on source code to permit access only by authorized users. These in-product access controls are applied to the underlying filesystem objects rendering it more difficult to bypass such restrictions.  
• Robust build auditing. A build audit will contain the precise versions of all source controlled files used to create a build artifact. This eliminates confusion regarding what changes made it into a given product release.  
• Support. Selecting ClearCase gives you near immediate access to a problem resolution team that can access specialists in various product areas. “System down” issues can be escalated for more rapid resolution. 

ClearCase’s weaknesses: 

• Cost. It is not an inexpensive product, and has a continuing support/maintenance charge. Mitigating this somewhat is that complex issues can be referred to HCL/IBM for resolution. 
• Relatively limited platform support. While mainstream Windows and Linux/Unix releases are supported, embedded platforms and non-mainstream operating systems are not directly supported. Additionally, MacOS support is limited. Unlike GIT (and other FOSS SCM tools like Subversion, CVS, and the original RCS), neither porting guidance nor source code are available, meaning that new platforms are only supported if sales for that platform would support the cost of the effort. 
• Complexity. ClearCase is certainly more complex that GIT, because there is more to it. Each of the above capabilities not present in GIT add some layer of complexity. ClearCase also includes multiple means (outside of source code comments) to attach meaningful information to changes and change sets with multiple metadata types. 
• “Maturity.” This is often considered a euphemism for “obsolete” in technology circles. While it is true that prior to the IBM/HCL partnership, investment in ClearCase was reduced, and IBM supported 3 different SCM platforms (Synergy/Change, Rational Team Concert, and ClearCase), HCL is significantly more focused on investing in ClearCase.

Architecture
Open Vs. Closed
GIT is a completely open environment, designed by and for open source developers. This developer focus has positive and negative aspects. 

The chief positive aspect is that – due to the fame of the initial author and original user, Linus Torvalds – the tool has wide adoption and a large ecosystem has grown around it. This means that any developer with any experience has at least encountered GIT in some flavor, even if it was just downloading files from GitHub. 

Unfortunately, while a newly-hired developer may “know GIT,” the plethora of client options may mean that the developer knows a certain “flavor,” or even only a given version, of GIT. They may also be fully versed in only one of the 16+ GUI options and not in the command line. Additionally, as GIT is still rapidly evolving, key behaviors may change between GIT versions. 

GIT’s open source nature also alludes to another potential issue. Abandonment. The primary trigger for GIT’s ubiquity is the Linux Kernel. While this means that GIT will likely be around for the foreseeable future, other open source change management tools also had large followings and are now marginalized at best. Those include the Concurrent Versions System (CVS) and Subversion. Both were hailed as advances and replacements for proprietary SCM systems, and both had large followings in developer circles, yet neither has a significant following today.
FOSS developers are at least as prone as anyone else to chase “the next big thing,” which can lead to a project going stale. Using CVS as an example, its last production release occurred in May 2008. 

Repository Model
GIT is a distributed version control system. Each developer using GIT has a complete copy of GIT repository on their local workstation, which by default includes all project history from the “remote” it was created from. All common GIT operations save “push,” “pull”, and “fetch” operate on this copy, allowing for completely disconnected development. 

This completely decentralized architecture has costs related to developer endpoints as well. Particularly:
1. As the project or product grows, disk space needs can grow more than linearly. Each GIT working area contains a full copy of the repository, and potentially 2 additional copies of each working file. 

• The repository copy, which contains all versions of the file that have ever been    committed. 
• “Staging area” copy, which contains uncommitted changes that have been staged as part of the next commit. 
• “Working Directory” copy. This is the copy that the developer is currently accessing or modifying. 

2. Since developer changes are not stored in the central repositories unless the developer explicitly pushes them to the “upstream” repository, backing up developer endpoints becomes even more critical. 
3. If the developer endpoints are laptops or other portable devices, those devices – and their backups – require encryption to safeguard corporate IP.

ClearCase’s shared-repository model significantly reduces storage consumption for developer workspaces and safeguards developer changes by committing “checked in” work to the shared repository and not a local copy. Use of dynamic views also significantly reduces the time needed to create developer workspaces since there is no need to copy entire repositories locally. 

Change Flow Differences
Git’s focus on radically-distributed user communities gives it some unique capabilities. Key among those are: 

1. Selectively push individual changes to remote repositories. 
2. Selectively pull (a.k.a. “cherry pick”) changes from remote repositories. 
3. Changes can be submitted to other repositories via specially-formatted email “pull requests” and “bundle” files.

These allow very selective propagation of developer changes, which is a great benefit when the development team is widely dispersed. However, their use requires careful process planning. 

1. These features can leave developer work history on their local repository, which can cause issues if regulatory or other concerns necessitate maintaining detailed development history. 
2. Multiple users pushing to the same branch of a remote repository may also introduce unexpected conflicts, even if those users were working in completely different filesets. This issue becomes more likely as a given project adds users and becomes more complex. 
3. Using a “pull” model where the project leads pull selected/reviewed changes from developers’ GIT repository requires that the repositories be both in a fixed location, and available during the project lead’s working hours. Neither of these is a given if the standard developer workstation is a laptop. 

#3 above essentially means that each developer could need a minimum of 2 GIT repositories in an “all pull” model. The first would be their local copy, and the second would be an on-premises or cloud-based GIT instance (using GitHub. GitLab, etc.). The change-flow would be: 

1. Developer creates cloud-based remote copy of primary project repositories. 
2. Developer then creates at least one local copy of the repositories for actual use. 
3. Developer makes source code changes and commits them to the local copy. 
4. Developer transfers those changes to their “personal cloud copy” through their preferred means. 
5. Developer sends “pull request” to project lead. 
6. Project lead either accepts and integrates, or rejects, the changes. 
7. Developer resyncs local and “personal cloud” copies of the repositories. 
   
   

Unfortunately, this model turns out to be quite difficult to use if the project uses GIT submodules for reasons that will be described below. 

Additionally, this selective change flow between repositories can impact build reproducibility. A recent example of this is the conversation thread at: https://forum.f-droid.org/t/where-is-the-vlc-app/108/25. 

Background:
F-Droid is an alternative open-source-only Android appstore. For various reasons, the F-Droid team builds the applications in their repositories from the published source code. In this internet thread, VLC, a common open source video player had to be removed from their “active” application list because of build failures, and application crashes. When investigating the issue: 

Problem quote: 
For example, VLC 2.5.2 requires libvlc to be built from commit 1c02164. But the version they distribute was built with libvlc from ef7c26f5a7 (you can get this from logcat, grep “core libvlc: revision”). BTW, this mismatch can be the reason why F-Droid’s VLC 2.5.2 crashes. Official 2.5.3 uses libvlc built from cbfa98bd98, which has not been published at all. 

Analysis: 
We see 3 different GIT commit ID’s, but there is no way to know the which commit is where in the timeline as they are based on SHA hashes. This leads one team to believe that this is a 
potential cause for application crashes. Additionally, an apparently-unavailable commit is referenced in the most-recently-released officially-released software. Given GIT’s ability to “rewrite history,” you cannot categorically prove – without having a direct copy of the GIT repository used to perform the “official” build – that your copy of the repository has the same changes used to build the official release. 

These are easily as much “process” as “tool” issues. GIT provides a labeling mechanism similar in purpose to ClearCase’s labels and baselines, it just happens in this case that at least one set of developers elected not to use them, leaving other developers to wonder if they will in fact be able to build a working copy of the open source project. SCM toolsets and processes are tightly intertwined, and the tools should facilitate or encourage SCM best practices. 

In contrast, ClearCase’s “change flow” in a distributed environment is an “all or nothing” model. All changes are by default replicated to all remote replicas of a given repository. This can, and does change when security or other concerns dictate “one way” replication from one site to another. However, in general, if the replicas of the repositories are in sync, then all changes are at all locations. This allows managers, or external auditors, to see the complete history of all changes made to the source files in any desired range of dates. 

Unlike GIT, ClearCase’s ability to selectively integrate/merge changes operates on the file level within the repository. Additionally, it is possible to add specific changes from one version of a file to another using an “insert” merge, and to remove them with a “delete” merge. As the source and destination versions are assumed to already be present in the repository, the developer does not need to run tools to process specially-formatted text files to integrate a set of changes, and the files in question do not need to be text-formatted-files. 

Workspaces and Multiple Repositories
Workspace Management 
Another area where ClearCase’s and GIT’s differing philosophies stands out is the area of developer workspace management and complex projects using multiple repositories. 

GIT simply does not have a concept of a developer “workspace” separate from the repository. This can lead to issues in an environment where current and previous versions of a project are maintained and delivered separately to customers. By far the simplest way to perform this task would be to create multiple copies of the “upstream” repository and work separately in those repositories, and for a relatively small project it will certainly work. However, when the project is large or complex, with a 20 GB repository (not including the “working copies” of files.). This can become very unwieldy very fast. The way to avoid this is to use “git stash.” Using the “stash” command is an area where the lack of user-friendly references can cause issues if there are multiple “stashes” done in your local copy of the repository. The git stash command uses references in the style “stash@{0}” to reference stashes. It becomes far too likely that – at one point or another – a developer will apply “stashed” changes to the wrong product version. 

ClearCase, on the other hand, currently has 4 separate developer workspace types and multiple ways to configure those workspaces, referred to as views. The current types are:

LAN-Based views

• Dynamic. This is a view that maintains a up-to-date, changing, image of the selected repositories. This type of view uses the least space on a developer workstation, in fact using none if the view is hosted on a remote system. Repository changes will be reflected in near-real-time as changes are made. This view type also provides functionality needed for ClearCase’s fine-grained build auditing. 
• Snapshot. This is a copy of selected repositories “active” contents at the time of view creation or last update. Selective loading and unloading of repositories is possible with simple one-step commands. This is one of the two view types most closely like a GIT repository, but with dramatically reduced space requirements as there is no full clone of the repository stored with the view. 

​Web -based views

• Classic Web view. This is almost exactly like a “snapshot” view, but is updated using standard web protocols (HTTP/HTTPS). This view type can be created and loaded by users who are not directly connected to a corporate LAN. 
• Automatic. This is a dynamically-loaded version of the “Classic Web” view. Where in a web view, the developer needs to know all the files that are needed before starting work, the automatic view allows on-demand access to source code without preloading. Preloading is, however, available to improve performance and support fully-disconnected use.

ClearCase’s wealth of workspace types would be of little use without some mechanism to manage the configuration of those workspaces. ClearCase provides 2 “out of the box mechanisms” to manage workspace configurations, and tools to automate custom workspace configurations.

Out of the box: 

• Unified Change Management. This provides a mechanism to base development activities on specific milestones (called baselines) in multiple component repositories. The ClearCase Administrator or a product/team lead developer creates projects and sets up the starting baselines. Developers simply “join” the project in the appropriate interface, and their workspaces are created and configured for them. Developers then work in their workspaces, which are attached to a personal change “stream,” and when they complete various activities, they can deliver them to the shared part of the project, where they are integrated. Updates to the shared parts of the project can then be pulled via a “rebase” operation. 
• View profiles. On Windows clients, view profiles can be used to provide standard starting points and also allow for change isolation. Those changes can then be “finished” and merged back to the shared part of the project. 

Automation 

• The command line components of ClearCase (cleartool and rcleartool) both provide the capability to configure a developer workspace using a specially formatted text file. These custom configuration files can then reference other similarly-formatted text files to allow for automatically creating complex view configurations. This allows developers to set up views using a library of “standard” configurations.

Multiple Repository Support 
Both GIT and ClearCase support the ability to reference multiple repositories in a single project. However, the 2 products do so in radically different ways. 
Git’s process for referencing multiple repositories is through GIT submodules, and this mechanism is not particularly mature or transparent.  

Creating a full “image” of a project using GIT submodules is a multistep process: 

1. “initialize” the main repository 
2. Clone the main repository from an “upstream” GIT instance, and initialize and clone the submodules. You can use git “git clone – recurse-submodules” to do this, but it may be necessary to manually initialize and clone the submodules in the event of an error. 

Some significant complications that arise in enterprise environments are: 

1. Once the “submodule” reference is created, the host information is largely fixed in stone, so changes in host naming conventions, or project moves require updating the git module information and pushing it to all users. Again, for a relatively small project, this is not a major issue, but once the number of developers reaches the dozens, who may have multiple local repository copies that need to pull the changes, it becomes more challenging.  
2. Working within those submodules is also a complex and non-trivial operation. Complicating matters further is that it is debatable whether all the available third-party GUI GIT clients fully support submodules.  
3. Git submodules do not work 100% transparently with git branches. For example, if a submodule is added on one branch, and a developer using that branch changes to a different one, the submodule directory and its contents become an “untracked” directory tree. Removing the directory then causes issues if or when the developer switches back to the original branch. 

As mentioned above, an all-pull usage model may not be possible using submodules because the location of the submodule is fixed at the time of creation. This means that it MUST point to a central repository. You can use the submodule as a read-only view of the second repository, but that adds unnecessary complexity to the project. 

In fact, one of the recommendations for using submodules is to limit their use if the developers are not going to customize or modify code in the submodules, instead using a dependency manager like Maven to download the needed libraries, etc., for read-only use. 

ClearCase, on the other hand, has mature support for multiple repositories: 

• A ClearCase view does not need multiple steps to configure a workspace for using a second, third, or fourteenth, repository. From the end-user standpoint, they simply “mount” the repository for Dynamic and Automatic views, or “load” the repositories in Snapshot, Web, and Automatic views.  
• Each of these operations can be done in appropriate GUI interfaces or command-line tools.  

• These repositories have logical names – known as tags – assigned to them instead of using a fixed URI. These tags are stored in the ClearCase “registry” and there may be multiple registries and registry partitions (regions). 
  
  

This mature support for multiple repositories allows for transparently reallocating or renaming server resources. If the repositories are moved due to corporate mergers or acquisitions; data center migrations; repository load balancing; etc., the location of the repositories can be changed centrally, eliminating the need for users to update their projects simply to be able to find out where the rest of the project is. 

Workspace Isolation 
Developers working on complex projects often need to work with multiple releases of their projects between developing future releases and supporting the current and previous releases. It often becomes necessary to have simultaneous workspaces, and for those workspaces to be isolated from one another. Sometimes this is due to legacy architectural decisions or environmental concerns. Examples include: 

• Hardcoded explicit instead of relative output file paths  

• Hardcoded file paths in multiple source files. 
• Paths relative to fixed locations, for example a source file path relative to the user’s “home” directory. 
  
  

With GIT, these hardcoded paths can interfere with parallel development use cases since the GIT repositories for these workspaces would all essentially need to be in the same location during builds. One online suggestion for Unix users was to use Docker containers for isolation if the current- and previous-version builds needed to run simultaneously. 

ClearCase dynamic and automatic views provide this capability “out of the box.” On Unix, ClearCase repositories can be “overlaid” on arbitrary directory locations (except for system directories) allowing for a very flexible development architecture. 

Security and Policy Enforcement
Git’s open and highly decentralized design creates some unique administration concerns. Security is only partially “baked in” to the product. Some of those concerns are: 

Traceability/accountability of code changes. 
GIT:  

• Allows you to have signed code changes using gpg, a third party Public Key infrastructure tool, but does not require signed changes by default. The same applies to pushing to upstream repositories. 
• A GIT user can change their user information to any arbitrary value.  Without an explicit mechanism to tie changes to a specific user, it may not be possible to state who made a given change. Use of “upstream” repositories that require some form of authentication (GitHub, for example) mitigates this somewhat. 

• GIT, in the interest of simplifying pushes to remote “upstream” repositories, allows you to “rewrite history” to combine changes spread across multiple “commits” in to one “master” commit. This muddies the “change stream” and limits visibility into the development process.  
• While you can use a third-party service like GitHub or Gitlab to ensure that only end users who have permission can push upstream changes, there is no mechanism on the end-user repository level to secure data access. 

​ClearCase: 

• Uses an end user’s operating system credentials to authorize their ability to make changes to source files. This eliminates the need for a third-party PKI solution to authenticate changes. 
• Users cannot change their user information to arbitrary values, as their OS-internal user ID information is what is stored in the ClearCase databases and is used to secure source code data. 
• The user performing a change, and when and where those changes are made, is indelibly transcribed in the ClearCase database. While the comments can be changes, the other information cannot. 
  
  

Source code access.  

• GIT:  If a user gains access to ANY copy of a repository, that user can make their own copy, or “remote,” which may only be known to the one that created the “remote.” Short of encrypting the developer endpoint disks, there is no mechanism to prevent this style of data leak. 
• ClearCase: provides rich Access Control lists for file and directory data, which harness the underlying operating system’s native security mechanisms, limiting the need for third-party access control solutions. If one is not granted access to a given file, access is not possible through ClearCase, nor is it possible to bypass ClearCase and access the data containers directly because they are protected with similar access control mechanisms through the underlying filesystem. 
  
  

​Process enforcement and automation. Both ClearCase and GIT provide methods to attach scripts to key events, and in both these policies are specific to the repository (or repository replica) being acted upon, meaning they are not automatically transferred with the repository copy.  

• GIT: policy/automation “hooks” must be manually applied by each developer to each copy of their repositories. It is possible for a developer to forget or refuse to apply those scripts, which can lead to concerns if some of those hooks are used to prevent certain GIT commands – like “rebase” – from being used. 
• ClearCase: Automation and policy enforcement scripts are not the responsibility of the end user, they are applied to the shared repository by a potentially-remote administrator, simplifying policy enforcement and management. 

Build Auditing
GIT does not provide any mechanisms to ensure that a given build is based on specific versions of files or specific commits. While it is possible to embed the most recent git commit ID into build output, as evidenced by GIT information pulled out of VLC above, there is no way to prove or disprove that the build used that commit short of building a second copy yourself and doing a binary compare. And this still may fail if the build used different versions of other build tools (IBM vs. Sun java compilers; Differing Visual Studio versions or service pack levels; etc.  

As seen above, building in a GIT-based environment presents challenges unless steps are taken to ensure that the repository state at the time of the build is adequately recorded, and that all potential build hosts have access to that repository state.  

ClearCase currently provides 4 separate build auditing tools that, when combined with dynamic views, allow for in-detail auditing of all input files for a given build.  

1. Clearaudit. Any build tool that can invoke an external shell can be enabled for build auditing through the clearaudit tool. All filesystem resources accessed in a dynamic view while the audited command is run will be recorded and consolidated. 
2. Clearmake. This tool is available on Windows and Linux/Unix. It does advanced build auditing of any compatible make based build, including advanced build avoidance by tracking builds across multiple build hosts, and bringing build artifacts created by other users into a current build if the current build would create an identical object file. This tool includes third-party make emulation, most significantly GNU make.  
3. Omake. This Windows-only tool is otherwise functionally identical to clearmake, but provides emulation for the Microsoft Nmake tool. 
4. ANT listener. Any ANT build can be audited using the ANT “listener” for ClearCase. This allows for finer-grained auditing of ANT build steps instead of auditing the entire ANT run using clearaudit. 

This dramatically simplifies third party audits because you can create a view that shows explicitly the files used for any given build as opposed to making guesses that depend on timestamps, labels or commit ID’s. If the build tools are also under source control, ClearCase can also provide explicit information about the exact version of the build tools used. This can be a critical use case for environments requiring 3rd party code audits or have other heavy regulatory requirements.  

Cloud Support
GIT’s highly distributed and open source model has allowed for various third parties to create cloud hosted GIT offerings, with GitHub and Gitlab being two key examples. it is also possible to host GIT in a “hybrid cloud” offering where there may be GIT instances using “On Premises” GitHub servers, private AWS servers, and semi-public locations like GitHub at the same time.  Unfortunately, this also may pose challenges locating the repositories if they are not created from a central location.  

ClearCase, at the time of this writing supports running ClearCase server processes on Amazon Web Services (AWS), provided any LAN clients are in the same AWS instance. Hosts not within that instance should use ClearTeam Explorer with Web or Automatic views. Like GIT, you can have multiple instances of a given repository in multiple locations, but unlike GIT, if the repositories are synchronized, all repositories will be known to all other repositories.  

Conclusion 
Selection of, or migration between, Software Configuration Management systems a process that requires a thorough review of organizational and individual project needs, as well as the strengths and weaknesses of the alternative tools. ClearCase and GIT are capable tools with differing strengths, weaknesses and design philosophies. GIT excels in environments where: 

• Development teams are relatively small; 
• Most developers do a significant amount of essentially-disconnected remote work; 
• Widely dispersed project teams (Less than 5 in any location.) 
• Projects are reasonably small (Repository size < 1GB) 

• Projects fit entirely in a single repository. 
• Storage of binary build artifacts is done outside of the tool. 
• Open development models where process enforcement is not a major concern; 
• Strict build auditing is not needed;  
• Preserving ALL development history is not a critical concern. 

ClearCase, conversely, excels in environments where: 

• Development teams are large (50+ developers) 
• Teams consist of groups of reasonably co-located users, either in a single campus or with sizable groups in multiple remote campuses. 
• Multi-Gigabyte repositories. 
• Projects consist of components in multiple repositories. 

• Binary artifacts (build outputs, compressed video, etc.) need to be stored with source code files. 
• Completely-disconnected work is the exception rather than the rule. 
• Strict process enforcement is a requirement. 
• Strict build auditing is needed for regulatory or legal-compliance purposes. 
• Preservation of ALL development history is critical, often for regulatory or compliance reasons.  
  
  

This does not mean that the choice is one or the other. It is certainly possible for projects or components to be simultaneously developed using both GIT and ClearCase, the HCL ClearCase GIT connector allows synchronization of source code changes between GIT and ClearCase, allowing GIT’s strengths in handling small teams and open projects to complement ClearCase’s strengths when those GIT projects become incorporated in larger projects needing ClearCase’s build auditing, process control, etc. 

​Author:
Brian Cowan
Senior Technical Specialist at HCL