Monday, May 21, 2007

SVN vs ClearCase

At a current client we just swapped over from using ClearCase and ClearQuest to using SVN with clear check in comments within our team and updating the ClearCase repository daily.

The change in productivity is striking. One team member mentioned today that he felt he was saving around 2 hours a day. If that's accurate then on a team of 8 people it's equivalent to freeing up 2 people every day.

It's not just the time spent waiting for version control, but those pauses people make to 'quickly' grab a drink or check their email so the pair are not there when the tool does finish. Not only that, everyone is having more fun too. No one likes waiting for hour glasses. Everyone likes feeling more productive.

Are any steps in your processes disrupting the flow of your work? Can a change of tools help?

The key is to work out the features of the current process that are actually require and which are just nice to have.

10 comments:

Premal said...

So what's the reason to save 2hrs a day ? It is possible that your clearcase is slowing down only because of fact its managing the huge big history ? Did you guys move the entire history from CC to SVN ?

Nigel Thorne said...

it is possible that CC itself was slow do to database size, but I doubt it. Lots of time is just spent doing a 7 step process instead of a 2 step process.

In Subversion we update every 15 minutes, fix any conflicts (at most 4 files, 96% of the time none). We TDD or Refactor for around 1 to 15 minutes then commit the changes.
The speed of SVN enables this practice. Without it we just can't get the turn around time.

Everyone doing this process throughout the day leads to us all constantly working on the same codebase so less time is spent merging conflicts.

With everyone integrating continuously throughout the day rework and duplication from 'two people writing classes to do the same thing' is reduced.

The rapid commits are all validated by the build box giving rapid feedback on each commit to make sure everything is fine. Giving the team a pulse.

Having everyone working on the same codebase means they can all work on closely related code without problems. This allows multiple pairs to work on the same story, which speeds up delivery.

All of this is enabled by the continuous integration.. which in turn is due to checkins taking 20 seconds.

"Did you guys move the entire history from CC to SVN ?"

No we didn't, however we are now at 3656 checkins with no slowdown of SVN.

Cheers
Nigel

Anonymous said...

I'm curious - how do you save so much time if you spend all this time checking and merging? It has to be tedious, even if the update process itself is automated...

I would think that teaching your IDE/editor/whatever how to recognize various constructs (e.g., filenames, classnames, etc.) and validate them to be unique when they are created, would be a far more efficient and effective model.

Perhaps it would also be appropriate to build a list of "names" (function, variable, class, file, etc.) that could be searched quickly and easily. Then a developer considering a new {something} could see if the {something} already existed in some form.

Of course, it may also be useful to look at project planning to see if work could be restructured/allocated so people are not accidentally duplicating work. I have to believe it is still frustrating to spend half a day developing the next "tetris" only to discover that your colleague across the aisle just checked hers in...

Nigel Thorne said...

We 5000 commits as of today. So that's 1350 in 5 weeks. Which averages 54 checkins a day, or one every 7 minutes.

Typically I spend maybe 5 minutes a day merging conflicts. Making frequent small changes lead to very few conflicts. Think TDD with red, green, commit, refactor, commit.

SVN works for us as an enabler, however we also have standup meetings each day and pair rotation every half day, so everyone known what everyone else is adding to the code, so the risk of duplication is extensively mitigated.

Anonymous said...

Here are some statistics based on my experienece in case anybody is interested.

I was the SVN administrator and a lead developer at my previous job. I spent an average of 1/2 day per month managing SVN. We imported our history from a cvs-based version control system. We started out with 39,000 checkins. Within a year, we were at over 55,000 checkins. That's an average of 100/day. Our old system would have choked and died. (The code base was ~1 million lines.) Most operations on the repository could be accomplished in less than a minute.

Piotr Gabryanczyk said...

How did you do the CC synchronization once a day.
Did you use an automated tool or manually?

I would be very interested in implementing similar solution in our team.

Peter

Nigel Thorne said...

We started with a manual process. We later abandoned syncing at all. We needed to keep track of which changes related to which requirement. We did that by starting each checkin comment with "Story: XXXX " then initials of the pair doing the change... then any details we thought were needed.

We configured TortoiseSVN to force a story number to be entered.

Works for us...

Anonymous said...

On the surface it would appear that the savings were at least partially due to the change in process rather than the change in tool. You don't describe the process used in ClearCase or whether or was snapshot or dynamic views.

From what you describe as the process you are using with Subversion, if you were doing the same process in ClearCase with a snapshot view on a shared branch its very hard to see where two hours a day could come from.

Nigel Thorne said...

I can't tell you how clearcase was installed on the servers or how it was configured. I believe it must be possible to use clearcase in a more agile way. We didn't find it. We didn't look that hard though.

If anyone has any idea how best to use CC in an agile team I would love to hear about it.

Unknown said...

Hi everyone!
I found this interesting article of CCase used in Agile.

Agile SCM and the IBM Rational toolset
http://www.ibm.com/developerworks/rational/library/jun06/lee/

Cheers,
Simone

GitHub Projects