RE: Converting ClearCase to CVS

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Tuesday, February 19, 2002 at 11:58:34 (-0800), Paul Sander wrote: ]
>> Subject: RE: Converting ClearCase to CVS
>>
>> Let's assume for the sake of argument that your salary is around $40/hour.
>> For $8000, you can't even cover maintenance of ClearCase for that number
>> of users.
>> 
>> On the other hand, if you share my experiencing of spending 1-3 hours per
>> *day* administering CVS, then ClearCase becomes competitive.

>How anyone could ever manage to lose so much time to administering CVS
>is beyond me.....  Hmmm.... sometimes an "expert" is just that -- a
>former drip under pressure.  ;-)

Well, the problems were largely due to user errors, corrupting their
CVS meta-data.  I also spent some time fixing corrupted RCS files, and so
on.  Plus, for users whose experience is limited to things like SCCS and
RCS (which in that environment was most of them), just having a source
code repository outside their home directory is a serious mind bender, and
so after the second time someone performed a checkout inside the repository
I hacked CVS to prevent such an occurance from happening again.  Cleaning
abandoned locks was a big time-sink, too.

And that didn't include remapping source trees when we imported new releases
of software that got reorganized between imports...

>I.e. with a perhaps all too ad hominem attack I'm trying to say that
>your past experience with SCM lead you astray w.r.t. CVS and in the end
>you ended up mis-using it to such an extent that it didn't economically
>satisfy your employer's needs.  K.I.S.S. is CVS' philosophy -- perhaps
>it was not yours.

Nope, I know very well how CVS was designed to be used, and I trained the
users in that way.  Regardless, there remained certain requirements that
could not be overlooked, and I worked very hard to meet those requirements
without violating the "CVS way".

>> >We do of course develop concurrently, and we make heavy use of branches.
>> 
>> Our demands were much simpler, and it still required that level of effort
>> to maintain.

>Without knowing details of either sitution I think you have vastly
>mis-interpreted the meaning of the word "simple".  Something that seemed
>"simple" to you obviously turned out to be exceedingly complex for CVS.
>You either chose the wrong tool for your requirements, or you chose to
>use it in a way that it was not designed to be used.

We used the concurrent development paradigm where it was appropriate.
Where it wasn't, we assigned single ownership to the source files.
Where concurrent development worked, we supported branches; where
it didn't, we minimized (or avoided) the use of branches.  When certain
classes of wide-reaching changes were due to be made, we disabled all
access to the (relevant parts of the) repository for the duration of such
changes and required fresh checkouts upon their completion.

Life doesn't get much simpler than that, within the context of CVS.

>It's no coincidence that much larger freeware projects make very
>adequate use of CVS without spending any money at all on support.

There's no doubt that many freeware projects, some of them large, benefit
greatly from the use of CVS.  I don't believe that they spend zero money
on support.  Again, there are those pesky hidden costs, e.g. the owner
of the server gets a report of orphaned locks in the repository and has
to clean them out yet again.

Even on my personal system where my toy projects make very few demands on
CVS (no branching other than vendor branches, no concurrent development,
no binary files, no reorganizations, no use of *info files, small source
files, few source files per directory, very simple modules, and a very stable
server), I can't claim that CVS just runs by itself 100% of the time.

>--- End of forwarded message from address@hidden