info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Converting ClearCase to CVS


From: Ajmal Chaumun
Subject: RE: Converting ClearCase to CVS
Date: Fri, 15 Feb 2002 09:27:28 -0500

Hi,

Amazing how these are very much similar to what happened here. I do not want to repeat the whole story, but would simply add this.

When we realized that going from ClearCase to CVS was still an option, we were told of the lack of features in CVS compared to ClearCase, e.g., no directory versioning, etc. However, even with those "deficiencies", this move has proved to be a worthy one: definitely one with lighter SCM processes, little admin intervention, users being productive within minutes.

It will be curious to watch for this trend with new tools like SubVersion ...

Regards,
/Ajmal.


> -----Original Message-----
> From: Mark [mailto:address@hidden]
> Sent: Friday, February 15, 2002 8:45 AM
> To: address@hidden
> Cc: Mark A. Flacy
> Subject: Re: Converting ClearCase to CVS
>
>
> --- "Mark A. Flacy" <address@hidden> wrote:
> > Out of curiosity, why are you moving from ClearCase to CVS?
>
> Okay, you asked. Here it comes. But my question would be why
> not move from
> ClearCase to CVS? This comes from my personal experience at
> multiple clients,
> some using CVS, some CC, some both.
>
> ClearCase has:
>
> - much large cost of tool and support (I think their in
> kohuts with $Oracle$
> and that they are learning software development and customer
> relations from
> Microsoft)
> - much more money to shell out if you need to work at
> different locations
> without depending "always on" conection over a network, to
> simulate the
> unwritten rule that the client and server need to be
> (logically) on the same
> machine to work. (even if you use multisite, you get to the
> added benefit of
> needing merge everything on each end, which kills most if not
> all benefit of
> multisite if both sites need to work on the same release/branch)
> - a much larger "tool admin" to "project/user" ratio. Are you
> spending more
> time on CM activities or babysitting the tool? Does you phone
> ring for CM
> issues or CC issues? Do your users that just want to checkin
> their work without
> needing a PhD from $Rational University$
> - cannot handle interopability, yes Virginia, you must
> purchase or obtain yet
> another tool to assist CC, and add that to your overhead
> activities to maintain
> this tool to compensate/help out CC. (how much did you spend
> on CC and how much
> is it still costing you per day?)
> - much more larger (and persistent) learning curve (and ongoing user
> frustration level, especially if the out-of-touch high level
> people that where
> sold the tool where also sold on UCM, the so called
> "out-of-the-box" solution)
> - no additional functional benefit do to "directory
> versioning", cvs add/remove
> per branch per file is suffiently equivalent/reasonable.
> (continue reading if
> you want to reply to this one about renames and moves) don't
> get me wrong, I
> think directory version is great, but its importance in the
> grand scheme of
> things is artificially inflated.
> - cost/amount of infrastructure that is needed,
> CPU/bandwith/servers. Its
> expensive to keep performance up. contrary to what you may
> find on CCUIG,
> clearcase is anything but efficient when it comes to disk
> space. You have the
> VOB and all versions, fine, but the VOB also has cache it
> maintains to send
> files to views and you must regularly free it up to get back
> disk space. Views
> do not save on disk space, beacuse to use a file, it must be
> _copied_ into the
> view (just like CVS). but views have an added benefit, they
> can collect and
> store deltas in a cache for more that one version of the
> file, that must be
> cleaned up to get back disk space. Oh, you need to update a
> few files in you
> view, CC needs to continuously export a file system over the
> network to each
> client, CVS just sends packets with just the deltas needed,
> when needed. CC
> functionaly does what CVS does for updating views/workarea,
> CC just needs a lot
> more of everything (CPU/bandwith/diskspace) to do it and does
> it at a different
> time (at file use or checkout vs workarea creation). So if
> you never use or
> view a file in a CC view or have a bunch of garbage in your
> repostory you will
> never use in a build or development, then CC can be more
> efficient. How about
> all those processes CC has up and running, dragging down the
> system, just
> waiting around to be used (or begging to be restarted/bounced).
> - Trigger processing on the client, and all the maintenance
> fun that goes with
> it <yuck>. why can't you have integration prcoess ing done on
> the server and
> have a web based tracking tool and not worry about users
> client machine setup
> and configuration? well now we can.
> - lousy vendor support, yes the CCUIG keeps rational in
> business, without it I
> think rational would be out of business.
>
> Okay, the way Clearcase stores elements is neat (hey, its a relational
> database), you can rename a element (the name is just metadata, like a
> tag/label is) and even track an elements movement around a
> repository (more
> data for the database). What's the value added benefit? When
> was the last time
> someone asked where a file was in the repository 5 months
> ago? Or, has this
> file had a different name before? Is the total cost to your
> business, by doing
> business with rational, worth being able to answer these
> silly questions?
>
> Then only thing going for ClearCase is merge tracking (UCM
> sure knows about
> this), that is really an asset. but coordinating merging in
> CVS isn't that bad.
> But if you branch for every silly thing, well... can't help
> that, we have a one
> to one relationship between branches and product releases,
> merging is minimal.
> Is all about planning, and ounce of CVS is worth a pound of CC.
>
> UCM - this is not a process, it is not CM, it is called
> change sets, its a tool
> function that has been implemented in the most convoluted way
> (adding a whole
> new command set and abstraction to protect you from you, I
> guess). Normally you
> connect to a tracking tool and tie file versions to a
> ticket/bug number
> whatever, for change sets. Why did they do UCM in ClearCase?
> don't know. Maybe
> they never learned the rule, "if it ain't broke don't fix
> it". Maybe they
> realized their bloated software does anything but work "out
> of the box", and
> making UCM is needed to hold people over till the army of
> CC/CQ admins, SAs and
> DBAs, can get things working right. But don't think about
> upgrading Oracle from
> 8.1.34 to 8.1.35 cause your CQ is at 2001 and only 2001a can
> handle Oralce
> 8.1.35. Oh, you need CQ 2001a, well that may not work with CC
> 4.1, you now need
> to upgrade to CC4.2. yadda yadda yadda. Okay previous
> versions where examples,
> but you get the picture? Rational must not know much about backward
> compatibility, OOD, where's RUP when you need it Rational?
>
> Unless your a CMM level 5 company, writing software that
> affects lives, spend
> more time writting/following process than producing code,
> Rational tools, may
> actually be counter productive to your company. The ROI is
> not in sight and the
> gap is widening. Cutting loses and movin on. May need to
> re-image PCs to fully
> recover from rational. :)
>
> I used to compensate/cover for rational like other CC
> proponents, but Rational
> folks rubbed me the wrong way one to many times, now I call
> it like I see it.
> Okay, more of a rant, but does this answer your question?
>
> Mark
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Got something to say? Say it better with Yahoo! Video Mail
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: address@hidden
> For additional commands, e-mail: address@hidden
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]