Sunday, November 08, 2009

[Misc] Subversion turns into an Apache Project: so what?

Since a few days it is official: The Subversion project has submitted to become an Apache project. It seems that the incubation phase will start soon. Now my question: Subversion is conceptually dead, so what difference does that make? Ok, let's discuss this a little more in detail:

The thing is: most developers (even myself) meanwhile understand the concept of DSCM systems and all available projects are stable, fast, have good communities and are reasonably documented. Even tool support (IDEs, ...) is decent. Having understood DSCM I wonder why I would want to go back to a centralised system like SVN. There is no benefit in there for me. If I want to work server based so be it: I can do this with Mercurial for example in BitBucket, with Git in GitHub or by simply installing the DSCM on an arbitrary server that has ssh access.

I had a discussion with an Apache commiter recently about this fact and about the future of Subversion. He believed, that Subversion could (or better should) go through a complete redesign to embrace features provided by distributed source code management (DSCM) systems like Bazaar, Mercurial or GIT. I personally question this future of Subversion. We already have three pretty good systems and a very competitive game is played here since the last two to three years. Subversion would start with a delay of probably three years. Until a stable version of a (partly) distributed SVN is out, all other systems will be settled and far ahead.

There is, however, one major feature DSCM-systems can not provide by definition: this is collaboration via locking. This is an important feature for collaboration on (large) binary files like Photoshop documents, multimedia files, vector graphics and the like. Merging of such documents is practically not possible, but many (software) projects partly rely on a significant number of documents of that sort. Keeping those in a DSCM system is not the best idea. My future scenario for distributed (software) development hence consists of two repository types: a distributed one for sharing text-based files (like sourcecode) and a centralised one that provides versioning and a very good locking (check-in/out) support for (large) binary documents.

Now as I understand it, Subversion is neither really good in locking nor management of binary data either. Also tools-support for non-programmers (who often work with such binary documents) is not so great. So what is the future of Subversion? I believe already today it is pretty much a legacy like CVS. Off course, there are so many projects using Subversion, that we will probably have to deal with it for the next decade (not that I would like to). However, the migration wave has started and most new projects will use one of the mentioned DSCM systems. How could a re-write of Subversion help? Well, the principles are so different that Subversion with distributed characteristics would be either a new project (and I doubt that we need a forth DSCM system, as mentioned above) or would keep a lot of the disadvantages of the old system.

But maybe Subversion could focus on the locking-based approach: this is a very much needed feature for many projects and I also do not see much competition (in the Open Source environment) here. A good repository for binary data could be a reason to stick with Subversion for parts of the development efforts.

Your ideas?

2 comments:

Thomas Keller said...

Subversion still has a future in corporate environments, which only slowly migrate to newer VCS than f.e. open source projects. My company for example is certified after ISO 9001:2000 and all their software development processes are either bound to CVS or SVN, which is not likely to change too soon.

While I thought as well in the past that subversion is more or less dead meat, I'm still amazed of the development pace these guys have, f.e. recent releases (1.5 and noteably 1.6) have gotten a much better merge support, handling tree conflicts saner already than most other tools do out there. (Nothing beats the monotone VCS in this case, however. If you want consistency and reliablility in a distributed system, this has to be your pick.) And 1.7 should finally see a removal of all the .svn directories which up to now clutter a workspace in favour of a single, top-level bookkeeping directory.

Alexander Schatten said...

Thanks for your interesting comment. It is true, the development pace is respectable.

I still believe, that SVN is conceptually outdated. No doubt though, that it will live in many companies for a long time...