ClearCase vs. Git version control [closed]

Question

We are using a multisite ClearCase repository, and often we require to merge and build our system. This merge and replication takes almost three days to be available across sites. Hence to be more efficient, we are planning to move to Git version control. Could you please advise of the potential drawback that we can encounter if we move to the Git from ClearCase?

Answer 1

@zzz777: Your question was asked in such a ClearCase centric view that it failed to be comprehensible to people who never used ClearCase before. In fact, Git is light years ahead of ClearCase, and it is the commercial SCMs that need to catch up with OSS systems.

I have experience with both ClearCase and Git, and I can tell you that the Find merges (mis)feature of ClearCase is a result of its (fundamentally broken) design based on versioning files, but in Git you don't need such a primitive tool to merge the shared branch to your private branch. ClearCase is file-oriented, and checkin-s are file based, and that's why you need the Find (files) to merge utility, but Git is commit based, and that is the right model, since when you fix an issue or implement a feature, the entire changeset or none of it are the only options that make sense.

Git has a very powerful merge feature, and it does the right thing. There are two ways to do what you are asking (updating your private branch to be the shared branch + your changes).

The most obvious is to do a merge, so while on your private branch you just do:

git merge sharedbranch 

then, if there are conflicts (really a lot more rare than in ClearCase), you resolve them and

git commit 

And that's it. As a bonus, because Git has all history locally, you don't have to waste countless hours, if you have lots of files, like you do in ClearCase, the merge is blazingly fast, by the time ClearCase in a dynamic view does a merge of 10 files, Git will probably finish merging 100, easily.

Using git merge means that you preserve history and if your history looked like this before the merge:

o---1---2---3 (sharedbranch)  \   a---b---c (privatebranch) 

after the merge it will look like this:

o---1---2---3 (sharedbranch)  \           \   a---b---c---m (privatebranch) 

This preserves the history of your changes and can allow others to review your work.

And remember, these are NOT file revision histories. These if the tree history, which is the only history that makes sense to store, even if branches differ only by one or two files. The state you want to preserve is the tree, not one file.

The second option is to use rebase, which means that you make it like it seems al your changes have been made starting from the latest code on the shared branch.

The command you use (again, while on the private branch):

git rebase sharedbranch 

The history tree will change from:

o---1---2---3 (sharedbranch)  \   a---b---c (privatebranch) 

to

o---1---2---3 (sharedbranch)              \               a'--b'--c' (privatebranch) 

So if you give Git some time to understand it, and use it a little, you'll see how much better is the Git model and how broken the ClearCase model is.

BTW, the evil twin problem in ClearCase simply does not exist in Git because Git does not track directories (trust me, you do not need that).

Also, if you ever had a configuration specification, which is a little more complicated with several branches and you migrated files from one branch to the other, you probably know how important the order of the rules in the configuration specification is, and how frustrating is to see old versions of files because the configuration specification is "wrong". That happens in ClearCase due to its base design, and, needless to say, that kind of crap can't happen in Git.

So, to conclude, Git does not have a primitive tool such as "find merge", because it does not need it. It has a superior model and superior merge model which actually works. It is lightning fast compared to ClearCase (CCRC static view or dynamic view, you name it).

The only place ClearCase could have an edge is the instantaneous update of the dynamic view, but that is also mitigated by the fact that you can type faster git checkout branch than you can update the configuration specification.

Answer 2

Problems that I have had in a professional mixed ability office:

1. Mutable History. You can do some really silly (and powerful) things with Git. This can cause source loss.
2. Auto Merging. This is the best feature of Git. But, we had to shut development down for a week to find the source code that went missing. MSVS has a happy issue with randomly changing line endings and if you don't pull from the repository regularly it gets confused, and changes get lost.
3. Push/Pull order. ClearCase handles the date ordering and history for you, but Git ignores it.
4. Staging. ClearCase (at least UCM) handles branch promotion and other things for you. Git does not. You will have to manage this carefully.
5. $ID$ Does not exist for Git. Version tracking from actual releases and problem finding from knowing what the version of the source file is will have to be handled manually. (I am not sure what your release process is.)

For you final code repository, I might suggest a release repository, either another source control system or a separate Git repository, that is managed and only accepts pulls.

I am currently using Git for my solo project, and it is fine. But, in a mixed-ability house with a variety of editors I would be careful. You can really blow you foot off without knowing with Git.

I have not used either, Mercurial or Bazaar. It might be worth looking at these as some of the problems go away, and they have features to mitigate some of the above problems.