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.
2 comments:
It was truly refreshing to read flip-side arguments in your post, which essentially questions why we still use CVS here at Eclipse but at the same time recognizes the challenges of doing so. The typically adolescent way of stating that tool X is better than tool Y, and that people who don't switch are intellectually-challenged is unproductive and a simple waste of everyone's time. You, sir, are a true professional.
I do take exception with a few points:
1. The Foundation does offer support to projects who wish to migrate from CVS to SVN, in that we do all the migration for the projects. However, as you've stated, inertia and time are huge constraints to overcome, and impossible to ignore, and for most projects, CVS simply works and is sufficient for their needs. Perhaps we could offer more support, but the Foundation staff also has time constraints as well, and switching from one versioning system to another consumes a lot of time for a lot of people, for little to no benefit (real or perceived) for the end user. Top it all off with lackluster (abysmal) tooling for administrators means as admins, we much prefer CVS for its simplicity and flexibility.
2. I'm hard pressed to agree with you about SVN offering efficient storage. Perhaps you're likely referring to BDB. At Eclipse we opted for FS, simply because BDB doesn't work well (at all?) over networked file systems where a cluster of servers read and write from the same data. This means we have revision directories with tens of thousands of files.
3. I feel your claim that CVS is costing us substantial amounts of time and money is a gratuitous argument. Can you back that up with actual numbers? Perhaps hours/week/developer?
Denis,
Thanks for your thoughtful post. It's great to get some insight from someone in the know.
It's great to hear that the Foundation provides support for migrating to SVN. I wasn't aware of this and could only find one page on the Eclipse wiki regarding SVN. What I was looking for was something that targets project leads, providing them with the information that they would need to switch including how to modify their build process.
With respect to efficient storage I was referring to the binary delta algorithm used by SVN when storing changes to binaries. I've found an interesting article on the topic that includes some real-life experience. It's interesting to hear about your clustered servers and filesystem-based data store. I wonder if the SVN team does much in the way of testing for that kind of scenario. If you manage to discuss it with them I'd love to hear about it.
Regarding the money and time cost of using CVS I have no hard numbers. My post is based on my experience using CVS and SVN daily over the past 12+ years. Notwithstanding my previous comments about Eclipse tooling, SVN is simply a better tool. Better tools enable people to be more powerful and to work more efficiently.
I understand that the Foundation has unique challenges in running a very large set of complex projects that must run 24/7. There are many related issues that affect the choice of tooling, many of them non-technical in nature. Without the drive and willingness to seek improvements and efficiencies, any organization will run with the status-quo. In this case the Foundation has an opportunity to tune the development process and improve the lives of contributors.
Post a Comment