Migrating Clearcase to X

Question

I was asked to choose an open-source alternative to Clearcase-UCM, and I need an advice what would be the best match. Given below are some parameters I've collected:

• Half of the development teams use the Integration view, development view, rebase and delivery methodology. The rest just work straight on their integration stream with private views as if it was trunk.
• all the teams use baselines for labeling versions.
• They claim to be facing merging problems with Clearcase-UCM, so the alternative must have merging capabilities well designed.
• Zero maintenance - there is no VCS admin for the tool.
• Windows based development, so the tool must have a good win32 support.
• IDE integration (eclipse).
• Mac-OS support.
• nice to have: migration tool.

What tool will fit both working methods (neither of the groups is going to adopt the other method)? I have svn, mercurial, and git as alternative so far. will one of them fit? Are there any other choices?

Answer 1

I can't speak for the migration tool, but mercurial has worked great for us. We have a mix of WinXP, Mac OS X, and Linux people and there haven't been any snags. I don't use an IDE, but I believe Aptana acquired the pydev group (Python for Eclipse) so I wouldn't be too surprised if they have that.

Answer 2

Whe using UCM and creating a baseline, you effectively identify a revision of a predefined sub-group of a repository (the UCM component defined within a Vob, unless you have define one all Vob as a component)

So if you are using SVN, Git or Mercurial, you must realize each of your UCM components will actually be one (SVN-Git-or-Mercurial) repository.

Plus, you will need to recreate the notion of UCM dependencies (the "edit baseline dependencies", which none of those tools have.)

The closest approximation principle is described in this SO answer: it can be done but remains manual.

Note: "Zero maintenance - there is no VCS admin for the tool."... errr good luck with that one:

• backup
• DRP (Disaster Recovery Plan)
• right access for certain repositories with "sensitive" content
• scripting and client encapsulation for certain operations
• ....

No mater what tool you will choose, you will need an admin (not full time, but still pretty involved in admin tasks)

---

Regarding "tracability", mainly represented by the activities in UCM, but also by the streams hierarchy allowing to define a merge workflow, it does not translate well in Git/Mercurial: those tools are different.

For Git, a commit is the closest thing of an activity, especially since a 'git rebase -i' (rebase interactive) allows you to redefine the content of a commit (a bit like when you select again an activity for a new checkout)
Regarding merging, since they are so easy in Git or Mercurial, there is no real "merge workflow" formally defined through deliver/rebase operation.
Rather private branches are created and used/merge as the user see fit, some of those branches being published to another external repository.

Answer 3

To some extent the technical parts are the easy ones to deal with - you can use it with MacOSX or you can't etc. The tricky bits are the the 'services' that you buy as part of the CC license, and those will not be obvious to developers, nor will developers necessarily even care.

Your company's assets will be sitting in repositories that are managed by the tool you select and moving from one tool to another is not always that easy. So, much depends on the lifecycle of your products. Are they out in the market for 6 months, 6 years or even longer? The problem with some of these tools have only been out there for a few years, and they are subject to fashion to some extent. Git is in favour, Bazaar seems to have fallen out of favour.

My advice would be to look at what Rational provide under your current arrangement and try to find a tool supported by a service provider that will give you an equivalent service. Then compare costs.

You may also want to think about how you will get your developers off ClearCase and onto the new tool. In my experience migrating tools is 80% about people. They may moan bitterly about it at the moment, but when things don't go so well with the new tool in your zero maintenance scenario then their view may change ... been there.

If they are having trouble merging there is no guarantee that going to another tool will solve it. If the problem persists after migration you will know it's not the tool that's the problem.

Any tool can be zero maintenance. It breaks, you don't fix it, and migrate to another 'tool of the month'.