With the recent announcement of their 1.5 release, Subversion (SVN) has clearly surpassed their original goal "to build a compelling replacement for CVS in the open source community". So why are all Eclipse projects using CVS as their source repository? I explore some of the reasons that go beyond the commonly extolled superiority of SVN.

In a new collaboration with the Eclipse Mylyn project, I've started working with CVS again after about 4 years of active SVN usage. Although I had used CVS previously (for several years) in my career, I had forgotten how bad it really is. After having near-instant branching, fast history retrieval, atomic commits, efficient storage, directory versioning, commit version numbers and web browser access, it is really, really hard to go back. What the Eclipse foundation may not realize is that using CVS is costing them time and money. So why CVS?

1. Tooling

Eclipse committers use Eclipse. From the early days, Eclipse has had really good support for CVS. UI integration is tight, and CVS plug-in features such as workspace-relative patches make it easy to collaborate with others.

The Subclipse plug-in for Eclipse is excellent, however it's still not as good as the CVS plug-in. The Subversive plug-in for Eclipse (which is now an Eclipse.org incubation project) is unusable in its current state.

One Eclipse committer claims that there remain some major usability issues with SVN inside of Eclipse. I'm not sure if he was talking about Subclipse or Subversive -- and in part I agree. If more Eclipse committers were using SVN, then these plug-ins would improve to the same polished level of quality seen in the CVS plug-in.

2. Inertia

Projects that are already using CVS have inertia in the form of commit history, tagging and branching habits, build scripts, etc. It's difficult to overcome this inertia. I've done it on several large projects, and it can be painful.

3. Training

Eclipse committers who use CVS daily are used to CVS and the way it works. Minor differences in UI paradigms of the Eclipse plug-ins and some larger differences with how SVN works take effort to learn and overcome. There is a cost associated with this, and people dislike change.

4. Lack of Organizational Support

Many issues facing the Eclipse project teams would be greatly diminished if the Eclipse foundation provided tools, tutorials, documentation, recommendations and guidelines for making the switch. With the right support, Eclipse could make the switch one project at a time over weeks, months or even years.

5. Time Pressures

Eclipse committers are already busy supporting Eclipse and meeting their milestones. The last thing they want is to be spending time learning new tools and managing project infrastructure. The perceived time-savings of remaining on CVS is a falsehood. I can't tell you how much time I've wasted waiting for a CVS update to complete.

Conclusion

Eclipse and Eclipse users suffer because of continued use of an antiquated source versioning system. The cost in time and money is substantial. With the right vision and organizational support, Eclipse can overcome their roots in CVS and become a more agile organization.

Update July 4 2008: A few Eclipse projects are using SVN for revision control. See Eclipse SVN technology projects for a list of technology projects in SVN.