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…

Leave a Reply