Changing from CVS to Subversion should prove smooth and you will have a much more robust and reliable tool while using the exact same workflow you're used to.
On the other hand, if you're considering change, you should not only shift tools, but shift paradigms. Centralized repositories are really going the way of vanishing. Why not being an early adopter of the most reliable and productive Decentralized repositories.
I'd look at GIT, Darcs, Mercurial. This will certainly lead you into a more difficult path, but can prove more valuable in the long run.
And for a migration standpoint I'd still learn Subversion, because that's what people are using now, but I would look at GIT because that's the kind of thing people will be using in the next few years. And there're tools as git-svn that allows you to work in a Subversion environment while still using most of the benefits from GIT, for example.
I would have to say that is HAS replaced CVS. The few times I find CVS users they are mostly fully aware that they are using a dinosaur and should have already switched. :-)
I still use CVS for a lot of personal source control that I can't be arsed to migrate over - maintenance of code, for the most part. Subversion I use for new code simply because I see it becoming the standard going forward within a certain band of the development spectrum.
ClearCase - we use this at work for our company's main projects. It has a few advantages but few that recommend it over the free Subversion. I would recommend a rigorous and lengthy evaluation period before laying out the serious bucks that IBM/Rational wants for it. Seriously.
I converted over to SVN as my primary version control system as soon as the fs-fs repository format was available. For various reasons I knew that putting my code in a bsddb was a bad idea (doing bsddb access in a reliable way has proven time and time again to be very difficult).
SVN makes a great CVS replacement. It's commands and workflow are amazingly similar, branches are usable without reading the man page...
As far as making the move to distributed version control... I'm torn. I tried that in December of 2005, for around a year. I tried about half a dozen distributed version control systems and found them to be rather immature in general. Darcs and at least one other left me with several wedged repositories that even darcs-developer assistance couldn't solve.
The problem is that all the people that were dissatisfied with CVS started working on SVN. There was a massive push to one new tool. Then, a bunch of people started a dozen different distributed version control system projects, diluting the talent pool for each one. So, I think progress is going to be much slower to get a usable DVCS than it was to get SVN.
I haven't really tried much in the last 6 months. I'm kind of expecting to have something useful in another 1.5 years (I said 2 years when I stopped trying different DVCS systems 6 months ago).
Things may be better now, but based on the amount of time I spent doing an eval previously I'm not quick to do it again.
A couple of point were clear from the replies above:
- It is much easier start off with SubVersion than to transition to it from CVS.
- "shift paradigms" is required as mentioned by AkitaOnRails. Ouch, this is a biggie. There was a decent learning curve for each developer on CVS. If parts of this is tossed out the window, the relearning will be somewhat costly. I started reading the free HTML book and indeed it does require some change of thought about source-control.
- Sean took over a year to evaluate and compare the differences. Another ouch in time-and-cost.