views:

147

answers:

5

Hi,

I have never used ClearCase, but have used Subversion and for a short period of time Perforce. The IT department in our company officially supports ClearCase and some people have their code checked in it and some people sort of use it as a back up storage.

I am still undecided on weather to use ClearCase itself or setup my own repository using Subverison. It will be a two or maximum of three person developer team. From people whom I have heard from, I got this perception that ClearCase is complex and is not worth learning as it might not increase the productivity. Is it true or is it wrong?

Thanks...

+2  A: 

I'd go for subversion. It has a cleaner interface and is more intuitive than ClearCase. In my company people often struggle learning ClearCase and teams are migrating to svn. Another good reason to use svn is that it's free.

Leonid
+2  A: 

Stay away from it! It has some features that svn is missing (like activities) but for sure with 3 people on your team is not worth.

Gaetano Mendola
+2  A: 

ClearCase is not complex, but it is quite different from SVN. And quite slow ;)
See ClearCase introduction.

I have already manage to have other repos working tree working directly within a snapshot view.

For large projects with complex merge workflow, ClearCase (especially ClearCase UCM) can be worth it.
For a simpler project (in term of merge workflow), SVN is enough.

See also:

VonC
"Merge workflow": see http://stackoverflow.com/questions/216212#216228
VonC
+3  A: 

Assuming you're limited to the two version control systems (VCSs) you mentioned, Subversion (SVN) will be clearer, easier and better supported in almost every respect, until you get to the point where you must support multiple branches.

When you need to merge code (e.g. bug fixes) into multiple versions, support parallel development of any significantly sized features or by a slightly larger team of developers then ClearCase, and more specifically the ability to develop in branches and merge them together easily, will become worth all the extra pain and complication - especially if ClearCase is already being managed for you.

Experience

I've used ClearCase with between one person (me) and more than 400 people, It has many day-to-day annoyances, usability issues and faults but it consistently allows us to get work done together. At all times the ClearCase installation had dedicated full time administrators.

I've used Subversion by myself and with one other person, and it works great day-to-day (with no administrators except for me) but it very occasionally but consistently becomes a significant source of frustration due to the fact it can't handle any significant branch and merge situations.

Why is SVN poor at supporting parallel development and branching?

SVN fails in the support of parallel lines of development because it has very weak automated support for merging branches together. In contrast all the other VCSs that I write about here have good support for merging branches together; for the common cases it is a zero effort operation.

Branching is the way that version control systems model concurrency in human life (e.g. two developers work on two different issues in parallel, or one developer who has multiple issues open at the same time). But branching is useless if you can't easily combine everyone's work into a coherent whole!

Branching can happen explicitly (in that they are named and understood by the VCS) or implicitly (as a normal copy of the files or a checkout). SVN supports both, but in SVN branching is usually done in a implicit limited fashion. Each check out is a branch but all branches are forced to be synchronised on every commit/update. This happens because SVN does not support easy merging of explicit branches and therefore explicit branches are rarely created.

As you're forced to synchronise with each other at every commit this decreases the potential parallelism within the team. It also leads to some less than ideal development practices as you cannot effectively use the version control system for your own day-to-day development needs. It ends up being too hard to try out different ideas in your own personal branches and you cannot make multiple commits while refining a feature. You are also more likely to commit too early and end up breaking everyone else's work until you fix the problem in your last commit.

The other major issue is that, since merging explicit branches is not well supported, SVN does a poor job of helping you move code changes between people and between branches. Imagine trying to fix a bug in both the release branch and the development branch; alternatively imagine two developers are working on a related feature and they both need to have each others changes, but only at controlled points. Using SVN you can accomplish these tasks but the VCS does very little to assist you and you must be prepared to manually prepare and maintain patches or ship around files.

In the other VCSs you can ask the VCS to merge a branch containing a bug fix or a feature into various other branches. At the end of the day all these branches (which themselves contain the contents of other branches) can then be merged back into the main branch. More often than not most of this will be handled automatically and correctly by the VCS, whereas with SVN having this kind of automatic flexibility and parallelism is almost unimaginable.

Large teams do get work done without strong support for automated merging but this places a greater burden on both the individuals and on team organisation, communication and process.

On the flip side, the downside of easy branching and merging is that you must be organised and rigorous about merging changes together at regular intervals as it doesn't happen automatically any more.

Other Options

Now if we take a step back and consider other systems, assuming your repository is mostly text based and relatively small (less than a few hundred MBs), I would suggest you seriously consider using BZR. BZR is at least as easy to use as SVN, especially if you already know SVN. It is also at least as powerful as ClearCase in all important respects from a developer's perspective; it supports multiple streams (branches) of development and has good support for merging them back together. At the same time it can support a centralised style of development as necessary.

Although I have no experience with it I should also mention that you can use the BZR tool to access an SVN server with bzr-svn and this may give you much of the benefits and merge capabilities of BZR while still having the advantage of hosting your code on the widely understood SVN platform.

While I just suggested BZR, in the world of open source distributed version control systems (DVCSs) many people appear to be going with GIT. I didn't suggest this though since it forces a much steeper learning curve on users coming from an SVN background and I think many teams in the wild would prefer the better Windows support and ease of use of BZR above the scalability and speed benefits of GIT.

If you choose to go with a DVCS like BZR or GIT you probably don't need to get too hung up on exactly which DVCS you start using. The widely used systems all support exporting and importing between each other and can all at least import from SVN.

Jared
Why do you feel Subversion is not good for scenarios where I would need parallel development and branching?
Manoj
Manoj: I've updated my answer to try and cover your question.
Jared
@Jared - `svn copy` can be used to explicitly branch and those can be named however desired. `svn merge` can merge branches back together (not that it does a great job). Though I largely agree with your assessment, SVN doesn't make merging and parallel development easy, I have to take issue with "explicit branches are not well supported" and related statements as being factual errors that detract from your main point. I'm no fanboy but I'm working on an SVN branch right now, and another team here commonly codes on personal branches and they merge back to the trunk when done.
Stephen P
@Stephen P - I agree with you from a technical standpoint and I'll try and make that clearer in another edit.My point of view is that merging is essential to branching and if the VCS doesn't have strong support for merging it in effect barely supports branching. How I've seen the tools used has so far supported this view. Users of tools where merging is easy branch frequently, while subversion branches appear to be rare carefully planned events.Maybe the ease of merging in other tools has made me overstate the difficulty of merging manually too. I'll look into clarifying this as well.
Jared
A: 

IBM is not going to suppoort ClearCase/ClearQuest any more, they are forcing thier users to switch to RTC (Rational Team Concert) which is much better than CC/CQ and has completely different ideology (Jazz). So, I would not recommend you to use this obsolete, outdated and ugly as hell (with UI from WIN 3.1 times) stuff.

Bashir Magomedov
Really Is this true! Can you cite a reference?
Manoj
I can't. That is what an RTC instructor (from IBM side) said to us. But try to google it. I'm sure there will be a lot of links :)
Bashir Magomedov