Migrating away from Clearcase

Question

We are migrating from Clearcase to another VCS (probably either SVN or Mercurial). For companies that have made this transition, what factors did they find important in sel

Answer 1

You need to take into account several criteria like:

• what kind of data policy can you support (strict central repository, with only part of it loaded on the developer workspace, meaning SVN)
• central or decentralized repositories, with full history duplicated? (DVCS like Mercurial or Git)
• what kind of merge workflow will you be likely to follow (long-libed branches with complex merges, or frequent rebase)

In term of migration (to SVN or Mercurial), it will be easier if you were using ClearCase UCM, because the baselines represent clear "timeline" (closest analogy to "revision") you can use to import in your other (D)VCS.
If not (Base ClearCase), you need to consider what portion of the history you really need to import.

Answer 2

A couple to add are:

• Performance: slow development tools interrupt the developers' thought processes
• Power (Functionality): How good is merging? Newer tools like git have much better merge support and tracking than old-style tools such as CVS and SVN. Git also offers very handy tools such as bisect that speed the development process.
• Community support: How widely accepted is the tool? You don't want to pick something that will be on the sidelines five years down the road.

Answer 3

Third party support. Does the system have a mature SCC provider for Visual Studio? (SVN yes, Hg's not mature).

Eclipse? Both have good support.

Are your developers used to being command-line commandos? Then third-party support / plugins may be a non-issue.

Answer 4

In general I would always go with the distributed version control system (DVCS). I haven't tried mercurial but git; but the premise here is the same.

If you use a centralized system you are bound to that structure. If you use a distributed system you are not. But just because you can distribute it you don't have to. If it makes more sense in your team to have a single central repository then do it that way.

What you should not underestimate is the power of local branches. Branching in a centralized system is rather cumbersome, developer or feature branches are seldom made. Developers rather have multiple working copies or keep unsafe changes in their working copy, to not break the build. With a decentralized system the developer creates local branch works on it. Interrupted by a show stopper bug, he switches back to the master branch fixes the problem, pushes the changes to the central repository and changes back to his feature branch. The workflow is extremely smooth.

Additionally the distributed nature of the system makes it a robust one. If the server is down, it is business as usual for the developers, they can even exchange their changes between each other.

Finally developers can take work home, on the plane, on the train or where every they like. They never loose the VCS capability and can make proper commits.

The result is that the behavior of the developers in regards to the VCS is defined by company policy, not the technology and you can change you policy at any time you like.

Answer 5

this is an old thread, but i wanted to contribute a bit. IMO, SVN has run it's course. Now in fairness, if you have around 50 or so users and don't do a lot of branching, then sure, it is not going to be any worse than CC. However, as old as CC is and as complex as it is, it still has a lot of mature functionality. so if you are a mature CC shop, SVN will not meet your needs. in fact, a best practice is to branch less and work off the main trunk. so a better choice (given the choices above) would be Hg. Also, i'm biased towards dvcs. true dvcs that is...and there are only 2 OSS choices: Hg and git. and currently one commercial system, plastic scm. if you're used to visual representation of your file history (vtree browser, or component tree browser in CC UCM, think that's what it was called), plastic may be a more viable choice. as i have seen it has the graphical vtree and something else, like branch tree explorer. i remember supporting CC where a lot of us would take turns on the whiteboard and draw out the "process" model. plastic has it built-in. anyway, again i'm biased towards dvcs...i suffered enough with svn and cc and trying to use expensive replication tools and mastership scripting. dvcs is so simple! if you're a hard nosed linux/unix dev shop, git may be a better choice. if more windows or a mix, Hg and Plastic look like better choices. more graphics and visuals with plastic. i think Hg misses a lot of the permissioning and access controls you are used to with CC...so plastic might have the edge here. hope this helps and good luck!

Answer 6

If you're migrating away from good-ol Clearcase ;-) take a quick look at Plastic SCM. Most of the basic concepts will be still there but all the painful bits are gone. And it's distributed. Check the following link: http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html