SVN Hackers Blog

The First Subversion 1.7 Alpha Release is Available Now and The Community Needs Your Feedback

The long awaited and highly anticipated release of Subversion 1.7 is almost upon us.  Like any successful open source project, Subversion needs active participation and feedback from its user community.     This  is especially true in the case of 1.7,  given its emphasis on client-side performance and  new client tools.  That’s why Subversion 1.7.0 alpha-1 has now been made available for user testing.    Major 1.7 enhancements include:

  • HTTPv2- a protocol rewrite designed to enhance performance by reducing the number of round trips between the client and the server with every request.
  • WC-NG – a rewrite of the working copy library that enhances performance by centralizing metadata storage and provides a foundation for supporting features such as shelving and offline commits in future releases.
  • svnrdump -  a new client tool that provides the same functionality as  svnadmin dump and svnadmin load, but  on remote repositories.   There’s no need for administrator access to the source or target repository on on the remote server’s filesystem.

A complete list of what’s new is available at  http://subversion.apache.org/docs/release-notes/1.7.html.  Download 1.7 now at: http://www.wandisco.com/subversion/download/1_7-alpha.  Contribute to the success of this major new release by providing your feedback at:  http://www.svnforum.org/forums/56-Apache-Subversion-1.7.0-Alpha-Support .   This is your chance to make a positive impact on the world’s most popular version control system and its more than five million users.


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.

Support for Mac OS X Added to the World’s Most Comprehensive Set of Fully Tested Free Subversion Binaries

Certified Subversion 1.6.17 binaries are now available for the Mac OS X platform.  These binaries work with Mac OS X versions 10.5.x and 10.6.x on PPC and Intel 32 and 64 bit architectures.  This software provides a complete, fully tested version of Subversion based on the most recent stable release, including the latest fixes.

To upgrade to the newest release of Subversion on Mac OS X and take advantage of the fixes and enhancements that it offers go to: http://www.wandisco.com/subversion/download .  You can register for free community support for the software at: www.svnforum.orgProfessional support is also available if you require secure, high quality online, phone and email support with guaranteed response times and automated access to the latest fixes and updates.

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.

The Next Frontier of Software Development: Social Coding for Subversion

WANdisco recently unveiled uberSVN - a major new product available free of charge that transforms Subversion into an open, extensible platform for application lifecycle management (ALM). In addition to plug-and-play flexibility and rich system and user administration capabilities, uberSVN provides the first-ever social coding environment for Subversion, taking enterprise software development beyond the limits of email, wikis, defect trackers, peer-code-review-tools and other applications typically used to manage projects.

uberSVN’s social coding environment reflects the convergence of social networking paradigms represented by Facebook and Twitter that foster instant communication and the collaborative development models of open source communities where software with features similar to these social networking sites was first used. And it’s having the same positive impact on software quality and developer productivity behind corporate firewalls that it’s had in the open source communities that deliver such market-dominating software as the Apache web server, Linux operating system and even Subversion itself.

uberSVN is organized around development teams and their activities. Each team has a home page that profiles the team members, lists the projects they’re working on, repositories they’re using and their latest activity and status. Team members can see each other’s real-time progress by simply subscribing to Twitter-like feeds that managers can also monitor.

With uberSVN, just like developers in an open source community, software engineers in corporate IT environments can rapidly exchange information and continually learn from one another. Peer review and continuous feedback are the norm. The overall skill level of the development team goes up and the all-too-common pitfall of reinventing the wheel is avoided. The end result is higher quality software delivered in far less time.

uberSVN is free.  Download it now at http://www.ubersvn.com/download.

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.