Downgrading from ClearCase to SVN/Mercurial

Question

At work, we're using ClearCase right now. However, there's a lot of overhead required, especially when someone does something stupid (like erase a view with multiple reserved check-outs on the trunk...). Since we're trying to lower our overhead and be as lightweight as possible, we've through about the possibility of ditching CC and going for something lighter (Subversion or Mercurial), seeing as how we don't use 90% of CC's features anyway. Does this sound reasonable or will we be trading our Ferrari in for a station wagon?

All answers are appreciated!!

Answer 1

From my experience, ClearCase has indeed a lot of overhead and we managed greatly with SVN.

I vote, "downgrade" (actually its an UPGRADE). ;)

Answer 2

I'd definitely consider a move from clearcase to subversion an upgrade!

Answer 3

I agree with the previous posters. Ditching the IBM product and moving to an open source source control product won't be a downgrade at all. You'll probably be happier with these lighter and easier to use tools. In our shop we're in the process of moving from CVS to SVN and have been quite pleased with the result.

Answer 4

Fourthing the recommendation that you switch. If you're not using the features, it's a poor business choice to go with the commercially-priced solution.

Now, there's an associated cost with the "free" solution, too. Neither SVN nor Mercurial are going to provide you commercial-grade support. If this is an issue, and it certainly can be for some situations, you might not want to do it.

Of the two that you mention, SVN is the one you should choose if you're currently using a centralized VC repository. Not only is SVN's operational model a simple and intuitive one, but SVN has simply the best documentation and developer community I've ever seen in an open source project. The user mailing list is magnificent, the developers are responsive and responsible to their users, and the Red Bean book is the single best piece of open source manual writing out there.

Answer 5

I have no problem with your "switch". It will be an upgrade if you do not have many inter-dependent projects using UCM.

I manage both SCM (ClearCase and Subversion) and do recommend Subversion for small to medium independent projects.

However, make sure your developers are not used to the dynamic views of ClearCase: it is an encapsulation of the file system allowing the user to access files from the network. To my knowledge, ClearCase is the only one with that kind of access.

And take into consideration the paradigm-shift:

• ClearCase is file-centric (every file you get is read-only, and you checkout only the files on which you do work)
• Subversion is repository-centric (every file you get is read-write, you checkin all modified/added/removed files in one atomic commit)

Answer 6

The major thing I've learned is that, more important than the product is the process.

If you've implemented ClearCase (CC) using an SVN-type model, then SVN will work just fine and be a lot cheaper.

On the other hand, if you use deferred branching, build-by-label, and dynamic views (or can), which we use to great advantage in saving time and effort, and improving reliability, you will seriously regret losing these features. (Not to mention build management, UCM, etc.)

I find most people use the first choice, which is like using a Ferrari in rush hour traffic...

Example? Define labels GA, SP1, SP2 (you can have as many releases between GA and SP1 as you like, not relevant, and remember, CC labels are NOT the same as SVN). GA was your base release, SP1 is your current release. SP2 is your next release. The current release is based on GA and SP1. The next release is based on GA, SP1, and SP2 (see CC config specs)

Begin QA. Development is doing ongoing work for the "next release", and users can reference (not change) GA and SP1, and can apply SP2. Maintenance is doing work to repair defects found by QA and can reference GA, and apply SP1.

Case 1: In ClearCase, the mere act of applying the SP1 label makes the fix automatically available to the Dev SP2 release team. No work. Nada, Zero.

In Subversion, you would be making the change on a QA branch, and then (hopefully, remember to) migrate the change to SP2.

Case 2: Before you ask, certainly, if you add an SP2 change, you will have to branch to add a subsequent change for SP1, as it would be in most systems.

In my world, real world numbers: Case 1 happened 122 times for my last SP (8 SPs per year). Over 800 changes per year I didn't have to make in ClearCase I would have had to make if I used the Subversion model.

Case 2 has happened 6 times since early 2002 when we installed CC.

Look at the process, not just the product.

(Sorry for length, it didn't atart that long :-)

Answer 7

We went from ClearCase LT to SVN and love it. We're saving a lot of cash in maintenance fees and everything is working just as well as before.

I just wish I had investigated Git or something like that before I recommended SVN.

Answer 8

I'd be interested to hear about how your branch structure is set up.

Why are users working on the 'trunk' of your product? (I assume this means your main branch). Wouldn't development branches prevent your developers from affecting the main trunk?

Why couldn't you introduce a trigger on the rmview script preventing users from removing a view whilst still having checkouts? This is quite a trivial exercise, and there are plenty of sources online (and I'm sure StackOverflow would provide you with answers if you ask!).

Another suggestion would be, if you have the cash already invested in IBM products (thus willing to spend money on a commercially supported SCM environment) you might want to have a look at Team Concert, and Jazz.

Answer 9

I have just been spending the past few weeks at my new job looking into SCM (Software Configuration Management) and ALM (Application Lifecycle Management) tools to adopt to replace CVS and support the adoption of Agile.

If you are looking for something that will support true SCM with parallel development and branching then there are probably more alternatives out there than you realise.

For a simple SCM solution look into the following:

• Accurev: This is an SCM tool that has native support for stream/parallel based development. It provides a very good stream browser giving you a graphical view of your streams and allowing you to graphically promote changes as issues or as changeset (enforces atomic promotes of a set of source files). It has a built in issue tracker to give you change management and let you work in a task based manner. With AccuFlow you can have even more control of your changes with workflow and Accubridge gives you IDE integration.
• Seapine Surround: This is a nice looking tool which works well for branching but not quite as advanced as Accurev. What is nice about Seapine is the integration with their issue tracking tool, TestTrack Pro and also their test case management solution TestTrack TCM (which combine into TestTrack Stuido). Finally they also have QA Wizard Pro which is a web and winforms automated testing tool.
• PureCM: This is another alternative which is quite popular but i have not looked at it in great detail
• Perforce: Another alternative in this space which i wasn't so impressed with but it does have some interesting niche features like the ability to compare and merge images.
• Plastic SCM: An imature product but very interesting to look at.

All of these solutions offer much better branching support than ClearCase have natively suppert concepts such as developer sandboxes (instead of using those crazy views in ClearCase), and verions snapshots. Esentially a readonly branch, a bit like a baseline.

If you have an extensive Rational deployment you might want to look into these alternatives:

• MKS Integrity: A nice well put together product which has excellent portfolio management tools with a nice built in test run view. All of its tools fall into one IDE and is very customisable.
• Serena CM: Again a nice enough suite with extensive tools around the core ALM solution. Very big portfolio management piece and there is a lot of buiness process support with their Mashups components and also support for prototyping.
• Telelogic: Ironically is now part of IBM and soon to be IBM rational. Its SCM solution (Telelogic Change and Synergy) is easily the best i've seen with the ability to promote code changes explicitly by task into a release build branch.

All of the above solutions support the same SCM concepts as Accurev etc but are obviously more end to end products and are enterprise scale.

We have at this point narrowed our choice down to either MKS or Telelogic.

My biggest point on this is that there are many, many solutions out there in between ClearCase and CVS/Subversion which are commercial but relitvely cheap.

Hope this was of use.

Answer 10

Things I liked about ClearCase that I haven't been able to do as well or at all in other SCM tools:

1. Working with developer branches was painless. In CC (UCM), you work in your stream (a.k.a. branch), and "deliver" a bunch of work to the integration stream. Meanwhile, other developers do the same. The integrator (maybe one of the developers) then does some testing on the integration stream, and makes sure everything builds and maybe smoke tests things, then recommends a new baseline, which includes the work from all developers. Meanwhile, you keep working in your branch. Next time you want to deliver (or before if you like), you see a new baseline is available, so you merge into your stream. In fact, you are forced to rebase if a newer baseline is available. I tried doing this in Microsoft Team Foundation Server, and SVN. First, I couldn't find a way to enforce a policy like the enforced rebase of CC, so I had to go and figure out which of my revisions I did since the last merge, and what was done in the trunk since then, and then merge from the trunk into my branch. Then when I wanted to merge my new work into the trunk, I had to re-merge all the stuff I just merged into my branch, plus my new work.
2. Developer branches were conducive to effective code reviews. When I was using CC, we reviewed everything. Practically, though, reviews took time, and we needed to keep working. Each piece of work corresponded to an activity in CC. Only when the review was complete did we deliver the activity to the integration stream. If the review required changes, I could decide to either make the change in the activity I did the original work (as long as no subsequent changes were made to files changed in that activity), create a new activity to address the review changes, or possibly blow away the entire activity and start over (again, as long as no subsequent changes were made). In TFS and SVN, once you commit something, you can't go back easily without blowing away subsequent work. So we had to find some other way to show our changes to other developers. This ended up being diffs converted to web pages, but still, we couldn't go on with more work without it getting blended with the work pending review.
3. Cross-platform development is made easier with dynamic views. I only have SVN to compare here, so maybe Mercurial or others are better. My goal was to make changes, build, test, debug on both Linux and PowerPC platforms (and Windows for another project), and commit a single changeset once I was happy it works on all platforms. For the PowerPC builds, we had a sun workstation (accessing the dynamic view) that we used to build and test for a target. It was slow, so we did most of our coding and debugging on Linux, and then build and test on the PowerPC before final testing on the (PowerPC) target, and finally a check-in. One way around this is network file shares. One issue I've seen here is version incompatibilities between Linux svn and TortoiseSVN on Windows. If you let Tortoise into a Linux repo copy, it changes the .svn files, and Linux svn then complains the version is too new. (We weren't able to upgrade our Linux boxes to a new enough svn because of the platform we chose for a target.) So I can't use my Windows diff tool in a Linux svn repo. If I go the other way, using a Windows check-out and Linux mounting the Windows repo, the symlinks are not preserved (which are needed on the Linux build).

I do not disagree, maintaining ClearCase is a nightmare, and will cost you money. But once it's setup, it can provide for a very good development environment. Especially when you start integrating with ClearQuest (defect tracking, which we also used for tracking code reviews).

As another responder stated, the answer for you is highly dependent on your process needs.

Answer 11

Sounds to me like you'll be happy in git/mercurial and probably not in SVN. OTOH, all my clearcase experience was tedious and unloving, so I would consider any "escape" action to be a very good thing indeed.

The distributed systems sound like they match your workflow better.

Answer 12

I recommend reading HG Init - a guide by Joel Spolsky on how to switch from SVN to Mercurial.

As some previous answers have mentioned, SVN and ClearCase basically work under the same paradigm, so when you read the article, you can pretty much substitute every occurrence of the word "Subversion" for "ClearCase" and apply it to your situation.

This is the writeup that finally convinced me to start using Mercurial at work.