Which projects still use CVS and why (other than "it's too much work" or "we are afraid of change"). That is, I'd like to know if CVS has any pros when compared to the competition.
Subversion vs CVS had some interesting CVS pros, but I'm more interested on VCS's in general, not just a comparison with SVN.
In a company where non-devs store everything but the kitchen sink in the repository, cvs only use half the disk space. (i.e. it will not fill up my laptop SSD)
The real reason I'm still on CVS is of course:
Well, if you believe Linus Torvalds, it appears that CVS has no pros compared to the competition.
For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company and I hate it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN (Subversion) users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan of Subversion for a while was "CVS done right", or something like that, and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right.
— Linus Torvalds. (2007-05-03). Google tech talk: Linus Torvalds on git. Event occurs at 02:30. Retrieved 2007-05-16. (via Wikipedia)
In "The New Breed of Version Control Systems" dated January, 29, 2004, Shlomi Fish comes to the following conclusion about CVS:
You probably should not use CVS, as there are several better alternatives, unless you cannot get hosting for something else. (Note that GNU Savannah provides hosting for Arch, and there is documentation for using it with SourceForge). You should also not use the free version of BitKeeper because of its restrictions.
Other systems are nicer than CVS and provide a better working experience. When I work in CVS, I always take a long time to think where to place a file or how to name it, because I know I cannot rename it later, without breaking history. This is no problem in other version control systems that support moving or renaming. One project in which I was involved decided to rename their directories and split the entire project history.
I cite this as another example in answering your request to "know if CVS has any pros when compared to the competition." At the time of this article, the alternatives listed by Shlomi included Subversion, Arch, OpenCM, Aegis, Monotone, and BitKeeper.
Even 5-6 years ago, the stated reasons for using CVS—aside from the "because we've always done this"—appear to be:
If you look at the common sites for open-source code, the three major players appear to be Subversion, Git, and Mercurial based on the widely used sites for hosting open-source projects:
Essential CVS 2nd ed. appears to be the most recent book published about CSV, and it is dated November 2006—based on an Amazon search. Whereas Git, Mercurial, and Subversion all have books recently published—Git and Subversion will each have new books published this November.
I was surprised to see that Drupal is still being developed with CVS.
Although there are plans to move it to git, it's going to take a while.
That's a good example for an innovative & rapidly changing project that uses CVS
(not by choice, I think)
Kind of like giving you the latest and greatest but making you ride a camel to get it.
One question I think worth asking: how easy is it to recover from minor repository corruption? I may be over-paranoid, but I prefer a repository I can deal with sensibly with a text editor. (Yes, I back up repositories. No, not every time I commit something. I could lose work.)
CVS, for all its faults, has a human-understandable repository. The files are arranged in the logical directory structure, one repository file to one source file, and they're in the easily understandable RCS format.