There are several problems with Subversion in its current state, which prohibit people using CVS from migrating over to it (yes, my asbestos flamesuit coveralls are zipped up tightly):

1. There is no import/upgrade path from existing CVS repositories to Subversion repositories. Until svn can completely import an existing cvs repository, with full branches, revisions, and historical data intact, it will not be an easy migration.
2. There is currently no way to run Subversion without DAV or a webserver. I'm speaking from experience here, because I run a fairly high-volume public CVS repository system called SourceFubar, and the repositories themselves do not live on a server with a webserver. It just doesn't make sense to do so. Subversion (in its current incarnation) requires a webserver to operate.

There are really only a couple of things stopping CVS from being better; atomicity at the directory level, and finer-grained control over access methods. Now with CVS having ACLs and no need to have local user accounts to have protected access to repositories, that is not such an issue. You can also have anonymous ssh access to repositories if you wish.

There's two schools of thought about the ssh vs. pserver security "problem".

1. Using pserver presents a security issue, because your password to log into the repository to commit data, check out data, etc. is passed in the clear, over the pserver protocol. Some see this as a major security problem. It isn't. If you have proper ACLs set up on the repository itself, where the users committing data do not have any local accounts on the box, all any attacker can do with that password is either commit more data, or delete existing data, and since it's all in cvs, you can just roll back if it happens (and connections are logged anyway, so you'll know who and where the attack came from).
2. Using ssh is more secure, and your password can never be gleaned during a man-in-the-middle attack. Although this is true, it puts your cvs server itself at risk of further attack. Not only can you never verify the security of a client machine (what if someone else (an attacking client) decides to ssh into your cvs server with a "valid" account from the "valid" box?), but you have to give the user a local account on the server itself, which means there is much more access to the server than there needs to be. All to save from having a password sniffed?

There are good points and bad points to either approach, but in the long run, using pserver is much safer for the code and for the server and the user's account itself. Not only is that password not the same as any other password that the user has, but since they don't have a local account on the box, getting that password gets the attacker absolutely nothing of value.

The atomicity can be an issue, if you don't know what you're doing. I've done major CVS surgery on directories, file renames, moving entire trees of directories under other subdirectories, and so on.. without losing a single byte of the historical data. It's possible, but it takes a bit of planning to get right.

That being said, Subversion looks good, but until someone can cleanly, seamlessly, and securely use it on a box that does not require a local account or a webserver, with the ability to import an existing CVS repository into it (full historical data intact), it will not catch on as fast as people hope.

CVS is well-seated, and lots of very high-volume projects use it, and continue to use it every day, including myself. I've wrapped a lot of tools around my public repositories to help developers manage their code better (4 different web-based code view/diff/graphing tools, cvs statistics pages, and other tools that enhance the usability of the repositories themselves), and these things just don't exist for Subversion. I'm sure that in a few years time, they will, but right now, it would be traumatic to migrate existing codebases over to Subversion.

YMMV though. For a completely new project where security isn't an issue, Subversion may be a perfect fit.