Arguments to convince to switch from CVS to SVN

Question

The UNIX department of my company currently uses CVS as source-version control system. They use it in a very strange way: different repositories for development/testing/production code (for the same project), no one tags anything, weird directory architecture, and so on.

The system has been set for ages but now, I have an opportunity to organize a meeting where I have to suggest changes. I'd like to make them change from CVS to SVN (Mercurial or Git might be even better, however I can't really recommand using a system I don't know well, and switching to SVN will already be a great step forward).

I don't have much experience with CVS so I can't compare them efficiently: I just know it doesn't support atomic operations and that it is deprecated.

What killer arguments would you use to convince my collegues to do the switch ?

Thank you very much.

Answer 1

Hmm, this setup sounds like a distributed VCS, so Mercurial or Git may match in very well. Multi-repository-setup is the speciality of it. I personally prefer Subversion, but in your case you should take a look at these, hginit may be a good introduction to Mercurial.

Anyways, arguments for switching:

• atomic commits
• better handling of binary files
• version control of directories (only SVN)
• properties on files and directories (only SVN)

Answer 2

Actually atomic commits are a deal breaker, not some tasty feature. For example, you want to commit 50 changed files. With SVN you svn commit and it happens that network fails in the middle of commit - your commit will be ignored. With CVS you will have a half of the commit in the repository, so now everyone will update to broken code and become unhappy and the daily build can fail and make everyone even more unhappy. With svn you either have a successful commit, or it looks like you have never though of the commit - the repository is always intact.