ZK, > 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. Regards, Arthur Barrett
