One of the most common questions I’ve been asked during the recent round of Subversion Live conferences is “When is 1.7 going to be done?” My answer for the last few months has been “I expect we’ll branch in a month of two, and release a month or two after that.” In an effort to help folks understand that answer, I offer the following. (And of course, in saying all this, I’m speaking for myself, not in any official capacity for the Apache Subversion project.)
Version control itself is a hard problem to solve, and no system out there gets it completely right. Subversion’s strategy of versioning files and directories in a centralized repository works great in the vast majority of use cases, particularly those in enterprise environments. Subversion 1.7 represents an effort to start to address some of the scalability and performance issues encountered by large Subversion deployments, especially those found on the client-side. The working copy metadata rewrite (WC-NG) is the key to this effort.
In a way, Subversion has fallen victim to its own success: so many people have deployed Subversion, and it is used in so many different ways that rewriting such a core component as the working copy library, all while maintaining existing behaviors, compatibilities and even bugs, turns out to be a very big job. Much bigger than any of the developers initially anticipated. And that’s just one feature: considering all the other bug fixes and feature enhancements which are also slated for 1.7, it’s a miracle we’re as far along as we are.
Releasing Subversion isn’t as simple as releasing a web browser or word processor. If your browser crashes, you have a good moan, fire it back up, maybe send a bug report, and then continue doing whatever it was you were doing. If your Subversion repository is corrupted, the data is gone, and most likely so are you as a user. As Subversion developers, we don’t get a second chance with your data, which makes us very conservative when it comes time to push out a major new feature release.
Right now the work focuses on finding and eliminating performance bottlenecks, and squishing major bugs. There are still somewhere around 30 outstanding bugs considered blockers for a 1.7 release. The developers think the work the rest of the work is well-scoped, but we could always be in for some unexpected surprises. So we just keep plodding along in our loosely-joined community of open source development, just like we always have.
One of the nifty things about this entire process, though, is that it all happens in the open, and you can be a part of it. Whether it be testing the new tools and functionality in Subversion 1.7, running performance tests, or just using a relatively recent version of the nightly builds in your everyday work, your feedback is invaluable to making Subversion 1.7 the best it can be, and sooner, too. So join a mailing list, post a bug report, or just start contributing. We’re looking forward to having you on board.
Subversion 1.7 won’t be bug-free—no software ever is—but we’re doing out best to make Subversion 1.7 the best version of Apache Subversion yet. Your data depends on it.