Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
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?
@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.
Problems that I have had in a professional mixed ability office:
- Mutable History.
You can do some really silly (and powerful) things with Git. This can cause source loss.
- 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.
- Push/Pull order.
ClearCase handles the date ordering and history for you, but Git ignores it.
- Staging.
ClearCase (at least UCM) handles branch promotion and other things for you. Git does not. You will have to manage this carefully.
- $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.
As I mentioned in "What are the basic ClearCase concepts every developer should know?", ClearCase might have some "decentralized" features with its multi-site repos, but it still a CVCS at its core:
it has a strong link with system user-id (which isn't relevant in a DVCS, where there is no unique user referential).
it has a unique repo for managing label and branch names (admin vob), while you can define a 'test' branch in 15 different Git repos without problem (except you need to know what repo1/test stands for, relative to repos2/test).
it also centralize a merge workflow definition through the (UCM) Stream hierarchy (you can visualize where you are supposed to merge a work from one Stream to another).
it proposes through UCM a definition of subset of codes (component), with dependency management. Git only has submodules, without override/overridden detection mechanism.
it manages any kind of files, even large binaries, while a DVCS (any kind of DVCS) is better off managing only source code.
The bottom-line (in our migration from ClearCase to Git) is that it involves quite a few refactoring/reorganization of the source code in order to have manageable Git repositories.
I've worked with both Git and ClearCase and once you learn how to use Git and then make the switch, you'll never look back. Make sure that you have the time to train your developers -- this should be your top priority. Git is an entirely different approach to SCM than ClearCase.
Some things to consider (possible downsides):
- You will need a true repository master, not just someone to watch over the source, but someone who understands how the SCM actually works (not just what a GUI displays to them) and can handle your branching model (see #2)
- Adopt/develop a robust branch model. A great example, and one I've used is A successful Git branching model
- You're going to have to invest a great deal of time helping your developers relearn everything they thought they knew about using/interacting with an SCM.
If you can overcome the three above, then there's very little downside (#3 being the toughest). As for @PAntoine, most of those issues are related to training -- #1 would have to require a truly poor decision to lose source code. git reflog will provide you access to every commit to the repository. The only way to destroy source would be through git reflog expire --expire=whatever refs/heads/master, git fsck --unreachable, git prune, and git gc, which should only be handled by the repository master -- and then there's the universal issue of a developer not committing their source (D'oh!)
Do you need a tool to help you with your software configuration management (SCM) or your version control [system] (VCS)?
That's what the ClearCase vs Git discussion boils down to.
So to speak you are comparing apples to oranges.
Thinking of ClearCase as just another VCS is a narrow view of what ClearCase is; stick with ClearCase if your goal is shipping the right product out of your shop.
On the other hand Git is probably the best VCS on the market at this moment, (though it does not offer any SCM support) so you switch to it if your concern is branching and merging .... (a side note the merging conflicts are the result of a poorly set base line and improperly configured views) ... VOB replication sucks - I give you that.
The drawback of your planned move is that you will throw away your SCM tooling support. And you will have to face a myriad of other tools and lots of manual work to achieve what you had out of the box with ClearCase.
Anyway a good VCS is the backbone of any SCM, so your move to Git might payoff in the long run.
