Suu:
There's a big, big difference between ClearCase and Subversion.ClearCase is a much more mature tool with tools to handle extremelylarge developer sites (like 300 developers). With MultiSite, ClearCasehandles your situation with ease. Of course, ClearCase costs a ton ofmoney (especially for 300 licenses), is a bear to manage, is slow, andneeds constant baby sitting.
I can't imagine a single Subversion repository handling 300 veryactive developers -- plus testers, documenters, requirement managers,etc. Subversion is still missing some rather important features. Itshooks are not as rich as ClearCase's triggers, and you don't have theUCM model like you do in ClearCase.
In fact, because of missing features in Subversion's mergingcapabilities, it cannot handle thedevelop-on-branch-and-merge-to-integration model that ClearCasehandles so well.
However, Subversion can be helpful in your environment if your 300developers are working on 25 or so separate projects, and you don'tneed the develop-on-branch-and-merge-to-integration model that UCMimplements.
The great thing about Subversion is the fact that you no longer haveto be concerned with the client side of things. Users can use whateverSubversion client they prefer. You don't have to worry about triggerscripts, licenses, or whether a user has the right equipment. Forexample, Subverion's hooks are handled on the server end which meansthat you only have to worry about hooks running on a single machine.ClearCase's triggers by contrast run on the client which means youhave to make sure your trigger scripts run on every single one ofthose 300+ clients.
Subversion has much better network security than ClearCase since youcan easily use Apache with https or svn+ssh. The best you can do withClearCase is establish a VPN or use the awful web interface.
Subversion is also network light when compared to ClearCase. EvenClearCase's "snapshot views" need server connectivity to function. Ifyou're not connected to the server, you have to "hijack" files inorder to edit them, then hope that ClearCase can figure out what isgoing on. The last time I used ClearCase with hijacked files, itsdefault mode was to overwrite the hijacked files and not check themout with the changes you made.
Many times, ClearCase also forgot to check the basis of my hijackedfiles. For example, I had version /main/5 checked out and I hijackedit. Someone checked in version /main/6. When I update my view,ClearCase detects that my file based upon version /main/5 washijacked, and gives me a choice of 1). ignoring the hijack, 2).checking out the file with my changes, or the default 3). overwritingthe file with what is on the server.
If I chose the second option, ClearCase would checkout the file in myview, and keep my changes. Unfortunately, my changes were based uponversion /main/5 and the latest copy is at version /main/6. If I checkin my copy, I would lose the changes in version /main/6. Not a greatidea. I hope that IBM has fixed this issue.
Subversion, on the other hand, allows you to make changes withoutconnecting to your server. (Not too sure how locks are now handled...)You only have to connect to the server on commits, checkouts (whichyou only do the first time you make a working directory), and updates.
There is even a package called SVK that allows you to have localcopies of your repository which is very similar to MultiSite. You useSVK to check in and out of your local repository, then later sync thelocal repository with the other copies you might have around theworld.
Whether Subversion is right for you depends upon a lot of factors. How"technical" are your developers? Can they handle straight /main branchdevelopment? Can they manage using a version control system without afancy front end that abstracts the development cycle? (Of course,Subversion is much easier to use than base ClearCase, so there may notbe a need for the big abstraction layer). Also are you talking aboutone really, really big project, or lots of little projects?
On 7/16/05, Suu Quan <squan@portal.com> wrote:> > > > Newbie here. > > > > Background: our shop is Clearcase/UCM, and it's not working optimally for us> -> investigating alternatives. One question: > > > > Situation: Our development teams (300 developers) are split 30% USA, 70%> India, over a not too fast network. I wouldn't call it slow, but it's not> super fast. (I've worked at 50% USA, 30% Singapore, 20% Gemany situation,> thus they were working 24 hours a day). So, my situation is not unique. > > > > If we have a single repository, say in the USA, then developers in other> continents will have to deal with our –not too fast, but decent- network. Of> course, one solution is to upgrade the networ$$$k. > > > > If we have distributed repositories, then developers access a local network> (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 l
ong distance? > > > > Thanks in advance > > > > Suu Quan > > Release Engineering > >
-- --David Weintraubqazwart@gmail.com
Received on Mon Jul 18 00:03:35 2005