We have and are paying for 100+ Clearcase licenses and 100+ MultiSite
licenses, and use UCM because of its integration to ClearQuest, winkin
and are adopting the UCM paradigm of development (merge dev branch to
We have 3 main projects (not UCM terminology), each branching into
several parallel releases (UCM projects). The graphical representation
of the release branches are ugly -> the configuration is complex.
I'm dropping Subversion, based on what you said (and also some other
people's assessments). It's just an academic attempt anyway, from the
grass root. Management hasn't bought in to anything yet. Changing tools
is labor intensive, so that's an uphill battle.
And where have I seen your name before? CCIUG?
From: David Weintraub [mailto:firstname.lastname@example.org]
Sent: Sunday, July 17, 2005 3:02 PM
To: Suu Quan
Subject: Re: Working across the continents
There's a big, big difference between ClearCase and Subversion.
ClearCase is a much more mature tool with tools to handle extremely
large developer sites (like 300 developers). With MultiSite, ClearCase
handles your situation with ease. Of course, ClearCase costs a ton of
money (especially for 300 licenses), is a bear to manage, is slow, and
needs constant baby sitting.
I can't imagine a single Subversion repository handling 300 very
active developers -- plus testers, documenters, requirement managers,
etc. Subversion is still missing some rather important features. Its
hooks are not as rich as ClearCase's triggers, and you don't have the
UCM model like you do in ClearCase.
In fact, because of missing features in Subversion's merging
capabilities, it cannot handle the
develop-on-branch-and-merge-to-integration model that ClearCase
handles so well.
However, Subversion can be helpful in your environment if your 300
developers are working on 25 or so separate projects, and you don't
need the develop-on-branch-and-merge-to-integration model that UCM
The great thing about Subversion is the fact that you no longer have
to be concerned with the client side of things. Users can use whatever
Subversion client they prefer. You don't have to worry about trigger
scripts, licenses, or whether a user has the right equipment. For
example, Subverion's hooks are handled on the server end which means
that you only have to worry about hooks running on a single machine.
ClearCase's triggers by contrast run on the client which means you
have to make sure your trigger scripts run on every single one of
those 300+ clients.
Subversion has much better network security than ClearCase since you
can easily use Apache with https or svn+ssh. The best you can do with
ClearCase is establish a VPN or use the awful web interface.
Subversion is also network light when compared to ClearCase. Even
ClearCase's "snapshot views" need server connectivity to function. If
you're not connected to the server, you have to "hijack" files in
order to edit them, then hope that ClearCase can figure out what is
going on. The last time I used ClearCase with hijacked files, its
default mode was to overwrite the hijacked files and not check them
out with the changes you made.
Many times, ClearCase also forgot to check the basis of my hijacked
files. For example, I had version /main/5 checked out and I hijacked
it. Someone checked in version /main/6. When I update my view,
ClearCase detects that my file based upon version /main/5 was
hijacked, and gives me a choice of 1). ignoring the hijack, 2).
checking out the file with my changes, or the default 3). overwriting
the file with what is on the server.
If I chose the second option, ClearCase would checkout the file in my
view, and keep my changes. Unfortunately, my changes were based upon
version /main/5 and the latest copy is at version /main/6. If I check
in my copy, I would lose the changes in version /main/6. Not a great
idea. I hope that IBM has fixed this issue.
Subversion, on the other hand, allows you to make changes without
connecting to your server. (Not too sure how locks are now handled...)
You only have to connect to the server on commits, checkouts (which
you only do the first time you make a working directory), and updates.
There is even a package called SVK that allows you to have local
copies of your repository which is very similar to MultiSite. You use
SVK to check in and out of your local repository, then later sync the
local repository with the other copies you might have around the
Whether Subversion is right for you depends upon a lot of factors. How
"technical" are your developers? Can they handle straight /main branch
development? Can they manage using a version control system without a
fancy front end that abstracts the development cycle? (Of course,
Subversion is much easier to use than base ClearCase, so there may not
be a need for the big abstraction layer). Also are you talking about
one really, really big project, or lots of little projects?
On 7/16/05, Suu Quan <email@example.com> wrote:
> Newbie here.
> Background: our shop is Clearcase/UCM, and it's not working optimally
> -> investigating alternatives. One question:
> Situation: Our development teams (300 developers) are split 30% USA,
> India, over a not too fast network. I wouldn't call it slow, but it's
> super fast. (I've worked at 50% USA, 30% Singapore, 20% Gemany
> thus they were working 24 hours a day). So, my situation is not
> If we have a single repository, say in the USA, then developers in
> continents will have to deal with our -not too fast, but decent-
> course, one solution is to upgrade the networ$$$k.
> If we have distributed repositories, then developers access a local
> (faster) and can also take advantage of the work done by other teams.
> I've gone thru the svn book and there is no talk about this topic.
> Question is: what is SVN solution for teams working over long
> Thanks in advance
> Suu Quan
> Release Engineering
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Jul 18 00:30:48 2005