CVS is not as bad as its evil reputation…

January 27th, 2008 by Ralf S. Engelschall

Many Open Source projects, including FreeBSD, OpenPKG, RPM5, etc., for historical reasons even in 2008 still use the old Concurrent Versions System (CVS) — a popular Version Control System (VCS) of the ’90s.

At its zenith, CVS was the ultimative king, as it really dwarfed the older RCS or even the ancient SCCS. CVS was revolutionary because of its “checkout and commit at any time, resolve conflicts later on demand” instead of the “exclusively lock in advance for conflict-free checkout and commit” approach of other VCS. CVS also provided nice global symbolic revision and branch tags on top of the per-file revisions and branches, a consistent command line interface, and many more. Hence, in the ’90s CVS was really everywhere.

But in the last 8 years the VCS world changed dramatically: today we have the more “modern” Subversion, Git, Mercurial, Monotone, Bazaar… and now everybody considers CVS to be “just bad” and everybody still using it to be just “technology agnostic”.

What about the mid-term advantages?

Sure, nobody today should still choose CVS for any new project, of course. But CVS is really not as bad as its reputation and it is IMHO unfair that too many people just blindly “bash” it all the time nowadays — just because something more “modern” exists today and despite the fact that those more modern solutions have their very own new problems and shortcomings.

What people completely overlook is the fact that the modern VCS often do not bring any short-term and mid-term advantage to existing projects which are still based on CVS. Because the VCS use case of those projects usually were already very well aligned with CVS‘ shortcomings (like the inability to version control directory changes, or the slow operation in case of large branching trees, etc). Sure, directory tree manipulations are cool and useful, but more for new and dynamic projects were you want or even have to still move around whole sub-trees, but you do not benefit very much from this feature in existing stable repositories. And as long as one primarily works on the main branch (HEAD) in CVS and uses not too long-living sub-branches, the speed issues are also not such dramatic.

So, please don’t misunderstand me: CVS is really dead in the long-term, but for mostly no project I personally know of (including RPM5, OpenPKG, etc) CVS really is a major show-stopper in the mid-term. That’s mainly because CVS is not as bad as its evil reputation and many people IMHO completely overestimate the practical drawbacks.

Advanced VCS features to the rescue

One really has to require advanced VCS operations to really fail with CVS even in 2008. But my personal experience is that most people, who today tell you that CVS is “just bad” and Subversion & Co are the new kings, never have done advanced VCS operations (like sub-sub-branching, subsequent branch-merging, automatic content verification during commit, cherry-picking of changes, etc.) theirself. Those people just think they really need a “modern” VCS with advanced features, although their typical use case is far away from being advanced. Sure, it is nice if the VCS provides new and advanced features, but for existing projects with clean and well-established CVS repositories this is usually not a killer argument.

For the regular use cases in software development projects CVS is most of the time still acceptable as existing projects usually do not change their well established VCS use case at all. So I would like to see people more fair and not all the time just “bash” the good old CVS and blindly stamp its users as “oldtimers”.

Upgrading is not a trivial “just let’s do it” task

Instead, I would like to wish those people to open their mind a little bit more and think also about the fact that CVS is not as bad as people tell you all the time and that upgrading a reasonably large project from CVS to one of the more modern VCS is far away from being a trivial task.

First, CVS is the VCS with the largest set of available add-on tools for access control and logging (e.g. OSSP shiela), web browsing (e.g. CVSTrac, ViewVC), IDE support (e.g. Vim plugin, Eclipse CVS plugin), etc. Only Subversion currently comes already close to this coverage of add-on functionalities. All other modern VCS still lack behind — partly even considerably.

Second, most of the modern VCS still have a problem in importing a really complex CVS repository because CVS allowed per-file branches, per-file tags, etc. and not all of the modern VCS support and are compatible with such notion and hence a reasonable “upgrade” (which really preserves the whole history) of an older repository is nothing one can “just do”. Often it means one has to ignore certain branches or at least not reconnect them at their correct original branch points.

Third, most modern VCS (except most notably stock Subversion) are actually of the class Distributed VCS. Distributed versioning is a very exciting concept and can open completely new possibilities. But most projects still use an inherently centralized development model with strict authentication and authorization requirements. And once you try to cover strict authentication with a real Distributed VCS you will be surprised how hard it is, as authentication inherently is a centrally and online backed concept and hence is in great conflict with the distributed and offline versioning concept. Some of the modern VCS not even have any type of support for reasonably hooking real authentication into it externally.

So what?

In short: CVS certainly is dead and nobody seriously should decide to still use it for any new project. But people should please stop bashing CVS just because more modern VCS alternatives already exist. Additionally, please understand that existing projects for good reason often do not have any pressure to upgrade, because CVS is not as bad as its reputation and still serves existing environments just fine — at least in the short-time and mid-term…

7 Responses to “CVS is not as bad as its evil reputation…”

  1. Tomas J Stehlik says:

    Dear Ralf, Thank you for your article.

    My question here is: Which of the many “new” version control systems would you recommend based on your extensive experience?

    Thank you very much.

  2. Ralf S. Engelschall says:

    Tomas: well, I personally currently strongly prefer Monotone (MTN) and hence use it in all my newer development projects. But Monotone is still under heavy development, although still stable enough for production use — by at least experts. Because of this status-quo and the fact that there are more third-party tools (Web browsing frontends, repository reporting tools, IDE integrations, etc) available for Subversion and most projects do not really need distributed versioning (and instead operate in the classical single central repository model anyway), I usually recommend others to stick with Subversion for their newer projects.

    But when one wants distributed versioning or at least want to benefit from Monotone’s great branching/merging approach (which is IMHO even better than what even Subversion 1.5 will provide), then Monotone should be given a try — even if used in a single central repository model. So, my recommendation for you: if you are a Unix hacker, give Monotone a try and fallback to Subversion if you do not become a warm feeling with it. If you are an average Unix developer than go straight into the Subversion road. If you are an IDE-based developer (e.g. via Eclipse), focus on Subversion (and its Subclipse plugin) only and do not waste your time searching for other VCS, too.

    Nevertheless, in case you want to evaluate alternatives, here is my personal ordered list of good modern VCS (in preference order from most preferred to lesser preferred): Monotone, Subversion, Mercurial, Git, Bazaar, …

  3. Suso Banderas says:

    Ralf, nice article. If you truly are asking the question “Why are people bashing CVS when it doesn’t deserve it?”. I’m about to give you an answer. Honestly, I would think you would already know about this having developed so much software, maybe you’ve just never accepted it.

    The obvious nature of the computer world is “out with the old and in with the new”. Constantly, even with software. The attitude is if there is a new kid on the block, be their friend and dump your old ones, maybe coming back to them once in a while when you need something.

    In programming, I don’t know how many times I’ve heard someone criticize someone else’s software as crap and then go on to write crappy software themselves. The cycle never ends. I try to write straight forward programs with lots of comments, proper indentation and a clear flow, but I’ve still heard people call it crap.

    The same is true from the software user point of view. Except that when its a publicly distributed program, the mob gets involved. And you wind up with waves of “I want the latest thing, everything before it is crap”. I hear it all the time. People criticize software without having even used it. Its annoying, but what are you gonna do?

    Someday someone might be crazy enough to try to write a better SSL tool than Openssl or maybe replace mod_rewrite with an abstraction layer. When that happens, I’m sure the same thing will happen. Without having even used Openssl, they will say that it was crap and that the new tool is what you really need to use, even though the new tool will most likely not even be complete or reliable. Maybe in the case of mod_rewrite some of those complaints will be warranted since its a big bowl of confusion. ;-) j/k.

    Like you, I’m also in the camp of thinking that CVS is a fine tool for source code management, it couldn’t have been used for so long if it wasn’t because subversion didn’t come along for years and git even goes back to the command line. Running a web hosting provider, I have to deal with this need for the latest thing all the time. The annoying thing is, many of these people who want the latest thing, don’t follow through and use it.

  4. Ralf S. Engelschall says:

    Suso: BTW, mod_rewrite I consider “crap” even myself as — if I would have the chance (and motivation) to write it again — I would do it completely different . At least from a configuration style point of view. The current crazy configuration style of mod_rewrite exists because of the nasty constraints one was faced with in 1995 when it came to the Apache config file parser. Today I would implement simple and single boolean expressions instead of the convolved RewriteCond+RewriteRule mess, etc…

  5. Ralf S. Engelschall says:

    Just an information in case you are interested: the OpenPKG Framework (the successor to the OpenPKG “bootstrap” package) recently was converted with tailor(1) from CVS to Monotone and the FreeBSD “src” (base system) repository these days was converted with cvs2svn(1) from CVS to Subversion.

  6. Paolo Bonzini says:

    I’ll follow up despite being a few months late.

    Something people have forgotten about the old times (before I started using VCS at all) is that RCS did not have at all a separate repository. Metadata lived right in the same directory as the data; most of the time different users accessed the repository using a network share, but nothing forbid using a VCS just for your own pleasure.

    Now, the same thing you can do today with all those DVCS that (like git, for example) share with RCS the same property of storing metadata in the same place as (or in a subtree of) the working tree. So that’s in my opinion the killer feature of these systems, like DVCS: they allow me to use version control from the start, setting up the repository in 10 seconds (git init; git add .; git commit -mimport), and thus have complete history for projects that I initially do not plan to make public.

  7. Tomas J Stehlik says:

    Dear Ralf, Thank you very much for your response from 30 March 2008. I didn’t ever realise that I’d received a response to my question, only now! ;-)

    Happy New Year to you and your family.

Leave a Reply