Release Notes

The Apache Foundation released Subversion 1.8 in July 2013. This major new version includes several significant new features, with the most notable client-side improvements being:

• Improved Renaming
  Renames to working copy items are now recorded as such, rather than as pairs of copy and delete operations.

• Improved Merging
  Subversion is now more intelligent about merging and will automatically choose the correct strategy to use when re-integrating changes. Explicitly specifying the reintegrate option on the command-line is no longer necessary.

• Inherited Properties
  Subversion now allows for properties set on a folder to be inherited by items located in a sub-path of that folder.

• Repository-Dictated Configuration
  1.8 introduces two new properties: svn:auto-props and svn:global-ignores. These properties extend the traditional auto-props and global-ignores configuration options but are stored in the repository and are therefore shared by all team members.

You can find out more about Subversion 1.8 from the Apache release notes.

Cornerstone and Subversion 1.8

Some of our users have contacted us over the past couple of months to ask when Cornerstone will support Subversion 1.8. This post will outline our plans for integrating 1.8 into Cornerstone.

First off, the good news: we will be integrating support for Subversion 1.8 into a forthcoming update to Cornerstone 2.7.

But unfortunately, we can’t currently say when. Why? The short version is that Subversion 1.8 (including 1.8.3, the latest version to-date) contains a bug that will need to be addressed by Subversion before we can roll out support. We have brought the bug to the attention of the Subversion developers and hope that it will be fixed in a forthcoming update, but we just don’t know for sure.

Read on for the long version…

Introducing Serf

Subversion has long supported two different HTTP stacks: Neon and Serf. Serf, while the technically superior HTTP library, is a less mature project and was not enabled by default. While use of the Serf-based HTTP stack could be enabled using a configuration option, most Subversion distributions (including our build for Cornerstone) did not even include the Serf components. It’s likely that very few Subversion clients used Serf in the past.

All this has changed with Subversion 1.8, which now uses the Serf library. Not only is Serf the new default HTTP library, but support for the Neon library has been completely removed.

Unfortunately, this switch to Serf causes major issues for Cornerstone.

Usernames and URLs

Ever since version 1.1, Cornerstone has specified the username in the URL when contacting a repository, e.g.

https://username@server.com/repo/project

This has always been supported by the Neon library for HTTP and HTTPS (as well as by the other stacks for SVN and SVN+SSH) but a bug in Serf causes HTTPS connections to fail as a result of errors during the SSL handshake.

HTTPS is probably the most widely-used protocol with Subversion, so it was immediately clear that we would have to address this issue before we could ship 1.8 support in Cornerstone.

Fixing the Issue

We started by investigating possible workarounds in Cornerstone, but it soon became apparent that this was the wrong strategy, so we decided to work towards getting the issue fixed in Subversion. A Subversion committer opened an issue having verified that the behavior we described in a post to the Subversion mailing list is a regression. This was a good start.

Initially we weren’t sure whether the issue lay with Serf or Subversion itself. While we had demonstrated that Subversion 1.7 exhibited the same behavior when Serf was enabled, the next thing we needed to do was determine whether the bug lay in Serf or Subversion’s Serf integration layer (ra_serf).

So we rigged up an Xcode build environment for Serf & Subversion and got debugging. We isolated the cause of the issue in Serf and posted details to the Serf Developer Forum. The Serf developers got on it right away and have already implemented a fix.

But this only addresses part of the problem. Changes are also needed in Subversion such that the URL’s username is used for authentication. These changes aren’t required by Cornerstone itself (we specify the username to the authentication stack by another mechanism), but this bug will prevent Cornerstone users from using their working copies with other clients until this issue has been resolved by Subversion.

The Prognosis

We’re confident that a forthcoming 1.8.x update will address the issue. We don’t know exactly when this will be but hope it will be soon, at which point we will release a version of Cornerstone that supports 1.8.

Until then rest assured that we are working hard to add support for 1.8 to Cornerstone.

Update

Please see this post for updated information on our plans for supporting Subversion 1.8 in Cornerstone.