[Top][All Lists]

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

RE: CVS future!

From: Arthur Barrett
Subject: RE: CVS future!
Date: Fri, 18 Jan 2008 06:39:16 +1100


> An employee told my CIO that CVS is being phased out
> so he came and asked me about it.  I am sure that is
> not the case for the immediate future from my
> research.  Can anyone comment on this as to the future
> of CVS?  

CVS is alive and well and being constantly developed.  It's been around
for more than 21 years and if it worked yesterday for you then it'll
work tomorrow just as well.

The 'ls' and 'dir' commands have been around for a while too and noone
seems to be saying that they need to be replaced in a hurry...  For the
use you described I would recommend sticking with the tool that already
is doing the job.

The project 'split' (for want of a better word) some time ago due to
different developers seeing different things as 'important': CVS, CVSNT,
OpenCVS, DCVS and SVN.  No tool is better than the other - they have
different strengths and weaknesses.  They are all actively developed and
all work on multiple platforms.

Starting rumours about the iminent demise of some project is a lazy way
to advocate for change.  There was a great article on the valuation of
IT assets published in The Financial Times UK Edition 36,501 on Monday
October 1 2007, and I believe the author will be releasing the complete
whitepaper soon.  Basically it talks about the lack of business cases
for the benefit of software and also the business case for maintaining
legacy assets.  The costs of replacing software like CVS for SVN are
astronomical and rarely worth it to the business, except perhaps that
techie employees who like playing with the latest gadgets are less
likely to leave that week/month for some other company, thereby reducing
employee turnover.

> I do plan on migrating to subversion at some
> point.

When choosing any software tool it is best to know what features you
require and then look for the tool that offers those features, or even
better look for what your goals are, then look for a process that
supports that, then look for tools that can implement that process.  For
instance knowing 'what' changed may be useless without knowing what else
changed - so you need to relate changes to one another and maybe
external events like project tasks, bugs or something else: so you would
need toos that support changesets and links to a system that tracks
those external events.

When replacing one system with another it is important to know the real
value to the business that the change will bring, and the total cost of
that change relative to the total benefit to the business.  See the
abovementioned FT article for more information.


Arthur Barrett

reply via email to

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