I often see posts on hacker news or proggit exclaiming how Subversion is dead and should not be used by anyone anymore. I do not agree with this but not for the reasons you might think.
Before I get to the reasons why Subversion will still be around for many years to come, let me rant about the anti-subversion movement…
Anti-Subversion Rant
I have a hard time when people lump CVS and Subversion into the same group. Subversion is vastly superior to CVS in almost every way. After working with CVS for a few years, Subversion was a breath of fresh air. People seem to forget that these days. True, distributed version control systems may equally be a leap forward above Subversion but that does not discount what Subversion did right.
When using Subversion with a small team, the merging and branching issues are not usually a problem. For commercial end user software, it has some benefits. For most commercial software, a centralized model for source control is beneficial. I love how the subversion revision number works. At my company we use it to identify the build. It works well to identify exactly what version a customer may be running. Git’s 40 character ID simply cannot be used in this way.
Subversion does have some things going for it especially when you intend to impose a centralized model anyway. Distinct product versions (1.0, 1.1, 2.0, etc) lend itself to this model. If you think about it, this is how commercial software always used to be. Web based products and continuous deployment kind of changed this which is why I think we have changed the way we do version control.
I still do think that DVCS is the way to go and will be the future of version control. I am currently looking into how to easily transition from Subversion to Git for our core product source control (using git+svn). I think the benefits out weight the few nice things we will lose. That is a topic for another post though.
Why Subversion will never Die
Now for the real reason Subversion will not die in the foreseeable future (particularly in the enterprise world). The real reason is the licensing. Consider licensing of Subversion. Subversion is licensed under the Apache license. The apache license is very commercial friendly as I’ve written here previously.
Alternatively consider the licensing of the various distributed version control systems:
- Git – GPLv2
- Mercurial – GPLv2+
- Bazaar – GPLv2
- Darcs – GPL
Notice a trend?
I totally understand why this is the case. The communities around these products want to protect from commercial companies who will fork these products, enhance them and not provide source for these changes. Typically if this was a client-server type model, it may be acceptable to have the core server licensed under GPL and have a library for accessing it under the LGPL. This would allow commercial offerings to freely build clients to these tools.
That simply cannot work here. Because of the nature of distributed version control systems, each user has their own repository. This means all of the magic that goes into providing a version control system lives as part of the client the user accesses. Licensing this under a commercial friendly license essentially provides that to the whole product. You cannot separate the ‘client’ from the ‘server’ in a distributed version control system as they are one and the same.
Perhaps it is easier to consider a case of this in action.
Embedded Version Control Support
Consider the popular text editor for Mac OS, Textmate. First a disclaimer, I am in no way involved in textmate and am just using it as a plausible example of the problem.
Textmate provides source control access within their editor to Subversion. They created a Java library called SVNKit for this purpose. I’ve actually used this in a product to provide subversion access from Java.
If you look at Textmate’s feature list, you will notice that they do not offer support for Git, Mercurial or any of the other GPL-DVCSs. They do have extensions for these but they cannot bundle support for it like they can with their SVNKit library.
The products I work on are in a similar state. We are excluded from providing Git or Mercurial support in our product due to the licensing. It may be possible to provide this as a plugin or extension that only drives the command line. Though technically possible, many of our enterprise customers would have issues accepting this especially when they have to download and install the GPLed version control software themselves.
Conclusions
As long as the distributed version control systems stick with the GPL license, they will be in exile from many enterprise environments. Perhaps some day we will have an alternative distributed version control system under the apache license. Until then, Subversion will continue to exist in the enterprise. Especially now with the community at Apache, Subversion will continue to grow and evolve for many years to come.