Arguments to convince to switch from CVS to SVN_问答_开发者

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 anythi开发者_如何学JAVAng, 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.

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)

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.

To be honest, if you have to work hard to convince them, then they'll likely be expecting it to fail (even if only subconsciously) and your effort might be better spent elsewhere.

I'd start using hg, git, or another DVCS locally (committing to the department's CVS repos) so you can get familiar with them. Due to their distributed nature, you can start realizing the benefits yourself, start showing the benefits to colleagues individually, and eventually make a strong case for conversion backed by real experience within your projects.

The question is - what specific problems are being experienced with the current CVS setup? Your reasons for change should address those. But if they are not experiencing any problems, change for change sake is not a good idea - CVS actually will do the job in a lot of cases. And if they are old-time UNIX guys, they probably remember some of the truly horrid version control systems from the past, and think that CVS is quite neat!

File renaming/moving! Taken alone, I doubt this is a compelling reason to switch, but it did have serious implications on a project I was on, once.

See, CVS doesn't let you rename/move files. If you rename or move a file, CVS thinks that the old one disappeared and the new one appeared, and that there's no connection between them. Although there's no real loss of revision history, you'd have to know that "File X" was actually "File Y" if you go back before some certain date. Oh, and the version numbers all get reset.

The project I was working on was a open-source Java app which had just started small and grew and grew, so everything was just in the package "core.*". When the time came to re-factor and put stuff into a nice package hierarchy... well, CVS reset all of the version info because, as far as it knew, we had just deleted the whole "core/" folder and created a bunch of new files out of thin air.

Supposedly, SVN is aware of files being moved/renamed, so it doesn't break version lineage. Don't know if Git does this.