Hyrum Wright's WANdisco Blog

Apache Subversion 1.7.0 Released

A few minutes ago, the Apache Subversion team released Subversion 1.7.0, the next major feature release of Subversion. Much has been written here of the new features in this release, and you can read more about them in the release notes, but suffice it to say that this release represents a significant improvement for all classes of Subversion users. From end-users to server administrators, Subversion 1.7.0 will enhance your version control experience. It really is the best Subversion release yet.

After 2.5 years in development the community is probably ready to take a bit of a breather, but instead they are already planning what will go into Subversion 1.8. At WANdisco, we have our priorities, which we think will improve the branching and merging experience for a large number of users. However, you may have other features on your personal wish list, so I encourage you to get involved in the Apache Subversion community, let them know what you want, and start making it happen. With good effort, and a bit of luck, Subversion 1.8 will be even better than 1.7.

First Apache Subversion 1.7 Release Candidate

Earlier today, we pushed the first public release candidate for Apache Subversion 1.7.0: RC2.  (RC1 was dead-on-arrival so it was never publicly shipped.)  This release candidate starts the clock on a four-week “soak” period to allow the community further testing.

A release candidate is just what the name implies: a candidate for release.  Barring any serious bugs found during the soak, this version of the software (or something very much like it) will become the final release.  As I’ve said before, those who test and report bugs will find they are fixed much sooner than those who don’t.

As usual, you can get 1.7 prerelease binaries for a number of platforms from WANdisco.

Update on Apache Subversion 1.7

I’ve been spending most of my time recently working on getting the 1.7.0 release of Apache Subversion out the door.  Bugs are getting squished, due to the efforts of the entire open source development community, and we’re focusing on stabilization and bug fixing.  Last week, the release branch was created, meaning that any more changes to what will become 1.7.0 now get extra scrutiny to ensure they don’t introduce any additional bugs.

Most of the feedback we’re getting from early testers is encouraging.  There are certainly bugs, but most are fairly benign and easily fixed.  What’s getting most of the testers excited is the performance benefits they experience, particularly on the client.  There will certainly be bottlenecks and areas for improvement after 1.7.0 ships, but the early results are encouraging.  (As for timing, I’ve been telling people late August, but that may very well get pushed into September.)

Even though we’re focused on completing Subversion 1.7.0, some of the developers are already looking forward to the next feature release: Subversion 1.8.  While it’s still a long way away, and nothing is set in stone, some of the suggestions being bandied about include improving merge correctness and performance, automating tree conflict resolution, and allowing more offline operations.  Of course, it’s an open source community, so the features people want to implement are the ones which will be addressed.

So take the 1.7 prereleases for a spin—you can find binaries for your platform at WANdisco’s download page—and let us know what you like, or don’t like, about the next release.  I think you’ll be pleasantly surprised.

The first Alpha, and the Subversion release cycle

On Friday, the Apache Subversion development community released the first alpha of what will eventually become Subversion 1.7.0.  While the event passed with little fanfare, it actually marks quite a milestone in the release process: the beginning of the end.  Lest anybody think that the final 1.7.0 release is imminent, I offer the following explanation of the Subversion release process, and how it will impact 1.7.0.

The Subversion release process is actually quite well-documented, but I’ll spare you the tedium of learning how we manage the CHANGES file, or what switches to gpg generate a detached armored signature.  Instead, I’ll highlight the steps that will most impact users.  And of course, I do so with my own voice, not as one speaking for the entire developer community.

The process started with the alpha release, which was basically a known-good revision of Subversion’s main development line, packaged and tested as a typical release.  The alpha is not free from bugs, and certainly shouldn’t be used in a production environment, but it does provide a readily-consumable baseline for folks looking to test the release.  There are still several release-blocking issues, and until they are fixed, we plan to continue releasing alphas every week or two.

Once all the release blocking issues are fixed, the release branch is created, and the first release candidate released.  These release candidates are exactly that: candidates for what will become the final release of 1.7.0.  In order to allow time for testing, we imposed a mandatory 4-week “soak” during the release candidate stage, while continuing to fix minor bugs and issues.  If additional major bugs are found during the soak period, we fix them, roll another release candidate, and restart the soak.

A few days before the soak ends, the release manager creates the final release candidate, gathers signatures, and it is this set of artifacts which eventually become the final release.  While this process may take a bit of time, that time helps ensure wide testing by the user community, and thus a higher-quality release.  If you’ve the time and inclination, I’d highly recommend trying out the alpha releases, and reporting any bugs you find.

A week in Berlin

Berlin!

Over four days last week, a dozen Apache Subversion developers were gathered in a conference room in Berlin with copious amounts of food and drink, and told to write code.  We were there at the behest of the elego Software Solutions, who sponsored a hackathon as part of their Subversion Day event.

In addition to giving us cool t-shirts, elego provided space and connectivity to allow us to focus on Subversion development, while discussing technical issues face-to-face.  This enabled some of the high-bandwidth discussion which really helps drive things forward.  During the week, small groups would break off to work out questions or design issues, while others would continue to write and test code.

Among the developers, we also had a larger plenary session to discussion higher-level topics of interest, including:

  • 1.7 release plan
  • Proposed features in 1.8
  • The project’s plans with regard to continued performance improvements
  • Improving the python tests
  • Handling of file externals
  • ra_serf performance and correctness

We also spent a bit of time crafting the next release in the 1.6 series and working on the blocking bugs for 1.7.0.  The general feeling was one of optimism, as we finally see the light at the end of the 1.7 release cycle, and work to fixing the last important bugs before branching.

And of course, since Subversion is an open source project, all the discussions were recorded on the mailing list and in the repository, both for people not spatially or temporally collocated.

I finished the week exhausted and ready to be home, but excited by the work that got done and the potential for the Subversion project.

Subversion 1.7: What’s taking so long?

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.