To SVN or Not to SVN? That is the Question...

Last week Denis Roy, the Eclipse webmaster, announced on the committers' mailing list that Eclipse has installed Subversion (SVN) and that Eclipse projects can make the switch from CVS to SVN if they choose. This leads naturally to the question should your project make the switch and, if so, is now the right time?

Before undertaking a project such as migrating to SVN it's a good idea to perform a cost/benefit analysis. So let's start with that.

The following is my list of the key benefits of SVN (a more complete list is available from the SVN project website):

• File history is maintained even when files are moved or renamed. This means when Joe, a refactoring whiz, takes a cut at your code you'll still be able to view your comments to give you an idea of what's what. As anyone who's moved a file in CVS knows, when a file is moved in CVS its history is left behind and it's difficult if not impossible to locate later.
• Commits are atomic. This means a commit only succeeds if the entire commit succeeds. (CVS has a nasty habit of having part of large commits succeed.) It also means revision numbers and comments are applied uniformly across all of the resources that were committed. So the next time you do a large commit that fails in the middle you won't have to sync and manually figure out what still needs to be committed.
  
• Branching and tagging take a constant amount of time. This can make a huge difference when branching or tagging a large project and means you can continue to work instead of waiting for the operation to complete and possibly getting distracted by the latest argument on Slashdot.
  

And here are some of the costs of migrating from CVS to SVN:

• Someone will have to migrate your existing CVS repository to SVN. Although Denis has offered to help with the migration this will still require Egon, one of your project's developers and a member of the release engineering team, to spend time on migration, time he would otherwise have spent on activities that will affect the project deliverable like fixing medium and low priority bugs.
  
• Your project's developers will need to learn SVN if they're not already familiar with it. This may not seem like a big deal as SVN is very similar to CVS in many respects but it will take a non-zero amount of time, especially when installing (someone's bound to run into problems) and learning to use the tools (which are not the same as those of CVS), and again takes away Egon and other developers' time to fix those bugs.
  
• Furthermore, the current SVN tools for Eclipse are not available from Eclipse but from Tigris through the Subclipse project. Some employers have strict policies on using third party tools and Daina, a developer working on the 'cuddly' feature, may need to seek approval from her employer to use the available SVN tools. (There is currently a proposal for an SVN team provider project but that has not yet been approved.) This means Daina won't be able to contribute changes because she can't use these tools until they've been approved by her employer.
  

OK. So there are some real benefits, although my experience with SVN is that I didn't see these benefits on a day-to-day basis, and there are some costs, the size of which will depend on your specific development team but will always be non-zero for existing projects.

Let's take a look at one other aspect of this migration project. I've been reading Joel Spolsky's book Joel on Software so let's take a lesson from Joel and look at this change from a consumer (that's Eclipse user or adopter) perspective instead of a developer perspective. What will your consumers gain from the switch from CVS to SVN?

Nothing!

This switch will not reduce the development time, add more functionality, fix bugs, or improve the testing of your project.

So, to me this is now a question with a simple answer. No. It's not worth the time to make the switch from CVS to SVN now, in the middle of your development cycle, as this switch will provide very little benefit to your project. Also, this switch will not benefit your consumers who, in the long run, will determine whether or not your project is successful.

Are you saying no Eclipse project should ever switch from CVS to SVN?

No. I don't want to suggest that all the Eclipse projects should stay with CVS forever. As I listed above, there are benefits for developers in using SVN instead of CVS. These benefits do have an initial cost that I don't think is worth paying in the middle of a development cycle, given that there is so much more important development work to do, but may be worth paying at the beginning of a development cycle. Making the change at the beginning of the cycle will allow your team to respond to problems early and should mitigate schedule slips later on in the cycle when you have less flexibility. Also, if and when the SVN team provider project is approved and produces tools that come with Eclipse this will remove the third cost listed above. With this in mind, if your project does want to make the switch I'd suggest holding off on it until after Europa (the next Eclipse release train scheduled for June) or whenever your next major release happens to be.

Defining the Eclipse Brand

Over the last few years Eclipse has experienced more than significant growth and has expanded well beyond its, what seems now to be modest, Java IDE roots. Eclipse now hosts 10 top level projects that contain 90 (if I counted correctly) combined subprojects with 11 project proposals currently sitting in the pipeline. The addition of each new project has broadened Eclipse's scope taking Eclipse in a new direction. The Eclipse community is thriving. Many great projects are being produced. But has the Eclipse brand, that is the name "Eclipse" and what it represents, grown along with Eclipse itself?

Take a moment now to answer this question yourself. Sit back, relax, and think about Eclipse. What's was your first thought? Was it Eclipse the Java IDE (aka JDT), SWT, or RCP? How about eRCP or DSDP? WTP, DTP, EMF/Modeling? Perhaps BIRT, SOA, or the ever popular Mylar? Or did you think of the Eclipse foundation?

My answer to this question continues to be Java IDE, SWT and RCP. This despite the fact that I'm a WTP committer and previously worked on the now graduated WSVT project. Comments such as this one (by mmm, try to ignore the negative aspect of the comment) show that I'm not the only one with this Eclipse brand baked into my head.

This type of brand problem isn't a new one and isn't one that's going to end with Eclipse. Let's take a look at two other projects, one that has already experienced this problem and one that looks poised to experience it as it begins to grow.

Apache started as the Apache HTTP server and I'm convinced that many people outside of the Apache community still think HTTP server when you say Apache. Of course today Apache is one of the largest open source projects in the world with numerous influential and ubiquitous projects such as Ant, Maven, Struts, Tomcat and Xerces. (I'd say that Woden, the Apache project I work on, has not been adopted quite universally yet.) And let's not forget Harmony, the Apache implementation of Java, which although not complete has already garnered much attention. Apache has experienced the same brand problem as Eclipse and it looks to me like this project has (perhaps unofficially) adopted a wait it out strategy assuming that one day people will get that Apache is more than the HTTP server. At present I think that the Apache brand has made some progress but it's difficult for me to gauge how much progress being part of the community.

Dojo is a fairly new project that started out, like Apache and Eclipse, with one key project: The Dojo Ajax Toolkit. Many people have heard of Dojo but I think most don't know that Dojo is also a foundation (like Apache and Eclipse) and Dojo currently hosts two subprojects: OpenRecord and Cometd. Dojo hasn't yet hit that critical point when rapid project growth begins but I think they're positioned well in the Ajax space, have the backing to survive the Ajax toolkit wars (I just don't see how two years from now we'll still have 100+ Ajax toolkits available), and therefore have the potential to grow their project base and scope. I don't think the Dojo Foundation has given much thought to the topic of the Dojo brand at this point but it will be interesting to watch and see how it tackles this in the future.

Looking at these two examples I don't think we, as the Eclipse community, have much strategy we can borrow. I think there is a lesson for new open source projects and that is building the brand of your open source organization on the name of its marquee project has shown that it can lead to confusion with respect to the other projects your organization hosts. I don't see a good solution for this as when forming an organization you want to cache in on the name recognition already in place. This lesson, however, seems to me like something that can be filed under good to know when forming an open source organization.

So what can we, the Eclipse community do to grow the Eclipse brand? I think we need to increase cooperation among the various Eclipse projects to create value add of using multiple projects together - something I don't think we're doing a very good job of today. In this way, when people think of Eclipse they won't just think of one project because they won't use just one project. They'll buy into the benefits of using WTP, DTP, ATF, Dali, and TPTP together. They'll explore the update site to discover other projects that will enhance their current tools. And once they see all of the projects as a single Eclipse offering they'll get Eclipse and the brand will grow.