Earlier this week, the Subversion community issued an RC5 release with the latest round of fixes. As we have done with previous releases, CollabNet is providing binaries for Windows, Linux, OSX and Solaris. The CollabNet Merge client and Subclipse have both been updated as well.

Here is a list of some of the noteworthy fixes I see (in order they were backported):

• r30741
  Fix bug whereby 'svn status --depth=files' still showed some dirs.
• r30743, r30751
  Fix memory leak in recursive remote propget.
• r30776, r30777, r30779
  svndumpfilter drops mergeinfo when it is *not* run with --renumber-revs.
• r30666, r30684, r30726
  Fix for issue 3181. Compare repository UUID with working copy when opening RA session
• r30761, r30762
  Fix for issue 3172. 'log -g' fails the moment it encounters a bogus mergeinfo which claims a merge from a non-existentpath@REV1-REV2.
• r30820
  Fix pool issue which definitely can lead to assertion failures in reintegrate, and quite possibly to other mergeinfo corruption.
• r30868, r30871
  In svnserve, tolerate unreadable passwd files. Don't error over svn+ssh:// when the user can't read passwd.
• r30843
  Fix abort in ra_serf when server sends invalid xml during replay.
• r30907
  Fix for issue 3185. Fix the 'log --limit' compatability code in ra_svn, ra_serf, and ra_neon to ignore nested logs when in '-g' mode.
• r30883, r30888
  Fix issue 3187. Fix reverse merges where merge target or subtree has non-inheritable revision ranges intersecting with the merged range.
• r30931
  Remove 'blind deletion of argument to mkdir --parents', delete only if this invocation has created it.
• r30896, r30905
  Make Cyrus SASL client support DIGEST-MD5.
• r30986
  Fix potential segfault in svn_io_remove_dir2(path='.').
• r29191, r29398, r29833, r30663, r30963, r30964
  Improve the responsiveness and accuracy of 'svn log -g'.

On April 24th, the Subversion development community released the first official release candidate for Subversion 1.5.  You can see the official announcement in this mailing list post.  You will notice that this release is labelled as RC4, and you might be wondering if you missed the RC1-3 announcements.  The answer is no, this is the first official release.  We go through an internal review period before we post any release.  Committers build and test the release and then either vote to approve or veto the release candidate.  In each of the first three tries someone saw something they did not like and so we vetoed the release.  Since version numbers are cheap, we simply increment when we try again.  That way, there is never any confusion about what someone is using.

Anyway, this is the biggest milestone for the release, short of the final GA.  The release of this release candidate can start the official soak period, which lasts a minimum of four weeks.  You can read about our release-stabilization process in the hacking guide we host on the web site.  As part of getting to this release candidate stage, we now have the release notes finalized, and you can see those online as well.  There is a lot of good overview information about the release in that document.

As we have been doing throughout the 1.5-development lifecycle, CollabNet is providing binaries for this release.  We want to make it as easy as possible for users to test the release and provide us with feedback.  Please provide the feedback, including positive feedback, as it helps us know that people are actually testing the release candidate during the soak period.  Sometimes if we do not get much feedback we will extend the soak period a little longer in order to allow time for people to try it.  So if you find bugs, please report them, and if things are working out well, then tell us that too so that we know you tried it.  Feedback can be reported on our forums on openCollabNet, or on the Subversion users mailing list on tigris.org.

In addition to getting the Subversion binaries, you can also try our new graphical merge client for Subversion 1.5 (based on Subclipse) and we also have links to the 1.5 release for TortoiseSVN and other tools.  It would be great if you could also try these tools out and give us and the developers your feedback.

CollabNet now hosts and supports AnkhSVN, the Subversion plugin for Visual Studio. Some of our goals are to help the AnkhSVN community grow and accelerate the development of the plugin. To kickstart this, we started by collaboratively creating a roadmap for AnkhSVN. Subversion 1.5 compatibility is number one on that roadmap, including good merge support. To properly support Subversion 1.5, we either needed to update our internal C# Subversion binding (NSvn) or take advantage of SharpSvn, a .NET binding for Subversion. We chose the SharpSvn route. To understand why, let's learn more about SharpSvn.

SharpSvn is a project started by Bert Huijben, who is also an AnkhSVN committer. The purpose of SharpSvn is not only to bring Subversion's API to .NET but also to abstract the low-level Subversion API away from the developer while still conforming to Microsoft's common language specification. The result is that SharpSvn is a Subversion client binding for .NET that works with a .NET 2.0 application or newer.  (Note: Since Subversion 1.5 and its final API is not yet complete, SharpSvn's APIs can change before the final release.) 

To show the value of what SharpSvn can bring to any .NET-based Subversion application, I created a simple Subversion Log Viewer using SharpSvn.

When you download and view the Log Viewer source, you'll see a lot of code that is primarily related to the UI and threading. I only use a few of SharpSvn's classes:

 
• SharpSvn.SvnTarget: Use this class as a target to run Subversion functionality against.
 
• SharpSvn.UI.SharpSvnUI: This class provides access to SharpSvn's built-in UI, for example when you are prompted for credentials or need to accept an SSL certificate.
 
• SharpSvn.Client: This is the actual client abstraction that gives you access to Subversion client functionality.
 
• SharpSvn.SvnLogEventArgs: Use this class to handle the events returned by SvnClient.Log().
 
• SharpSvn.SvnChangeItem: Use this class for objects that hold information about changed items retrieved via SvnClient.Log().

And here is a major part of the SharpSvn code in the example:

/// <summary>
/// Retrieves the Subversion log entries and potentially updates the
/// DataGridView in a streaming fashion.
/// </summary>
private void retrieveAndRenderLog()
{
    .....
    // The Subversion target to run log against
    SvnTarget target;
    
    // Attempt to create an SvnTarget by parsing the targetPath
    if (string.IsNullOrEmpty(targetPath) ||
        !SvnTarget.TryParse(targetPath, out target))
        {
            .....
        
        // SvnClient is disposable, using makes sure it's disposed every time
        using (SvnClient client = new SvnClient())
        {
            // Bind the SharpSvn UI to our client for SSL certificate and credentials
            SharpSvn.UI.SharpSvnUI.Bind(client, this);
            
            try
            {
                // Run the log subcommand
                client.Log(target,
                delegate(object lSender, SvnLogEventArgs le)
                {
                    .....
                    // Iterate over each changed path for each log entry
                    foreach (SvnChangeItem path in le.ChangedPaths)
                    {
                        tooltip.AppendLine("");
                        tooltip.Append(path.Action + " " + path.Path);
                        
                        if (path.CopyFromRevision != -1)
                            tooltip.Append(" (" + path.CopyFromPath +
                                "[" + path.CopyFromRevision + "])");
                    }
                    ..... 

SharpSvn is very performant and a simple to use API when writing .NET-based Subversion applications.  It is  easy to figure out what classes/APIs are necessary to get things done and the documentation in the SharpSvn project, and help provided on #ankhsvn (the irc.freenode.net channel for AnkhSVN), allowed me to put together the example application in less than an hour.  You will also be happy to know that SharpSvn alleviates the need for you to manually maintain the authentication callbacks, baton objects, aprpools and other low-level things that you are left dealing with while using other language bindings.

The SharpSvn's client API is completely in sync with the Subversion 1.5 client API and is the core of the future AnkhSVN 2.0 release. The code quality and completeness of SharpSvn is impressive. If you want to get involved with the development of SharpSvn, visit the project on openCollabNet.

For many folks, the forthcoming Subversion 1.5 release gets billed as something like "merge tracking and some other stuff". It's probably true that the work put into the new merge tracking feature outweighs the investments in other individual areas. But of course, Subversion 1.5 isn't about merge tracking alone. There are several other major features coming in this release. And as you'd expect, the Subversion community has made countless bugfixes over the past year-and-a-half, too. But today I want to briefly talk about one half-bugfix, half-feature, that might have slipped in under your radar: merges from foreign repositories.

The Subversion project has issued a beta1 release on the path to the final GA. The next release will likely be rc1 but, as always, that depends on the feedback we get from testers.

CollabNet has created binaries for Linux, Windows and Solaris (with OS X coming soon) from this beta1.  A noteworthy change as we get closer to RC1 is that we are now providing our CollabNet Subversion packaging for all three platforms. Solaris and Windows are new with this beta release. In addition, for all three of these platforms the server installation can automatically install and configure ViewVC as part of the server installation.

You can download these binaries from openCollabNet. There are also updated versions of the CollabNet Merge Client, Subclipse and TortoiseSVN available on this site.

We have a forum where you can post questions, comments or problems that you encounter using this version. If after some discussion a report is indeed deemed a defect, we forward the bug to the Subversion community using their normal processes. Feedback on the GUI merge clients will go to CollabNet Engineering.

For those that missed the announcement of the Alpha2 release, here are a few things to be aware of:

• Subversion 1.5 client has an updated working copy format. Once an SVN 1.5 client updates a working copy it will be converted to the new format. This means that older SVN clients will no longer be able to read these working copies. So either be careful, or be sure to update all your clients to the same version. There is a Python script that you can use to downgrade your working copy to the 1.4 format.
• Subversion 1.5 server can be used to serve an existing repository, but you will not be able to use the new merge tracking features with this repository until it is upgraded. You have a few options here:
1. Dump existing repository, then create a new repository using the 1.5 binaries and load the dump file.
2. Create a new repository using 1.5 binaries and use svnsync 1.5 binary to transfer the contents to the new repository.
3. Run a new command svnadmin upgrade to upgrade an existing repository. This runs fast as it just updates the internal repository format. There are some downsides to this approach though:
• SVN 1.5 repositories maintain a new index called the node-origins index  This is needed to speed up certain merge operations. The index will be lazy-populated on upgraded repositories, but can be updated on demand by running a new tool named svn-populate-node-origins-index(.exe). If you have a large repository you will likely want to populate the index. New repositories, or ones that are dumped/loaded or svnsync'ed will not need this.
• For fsfs repositories, the node-origins index will be slightly faster and take up less disk space if the repository is reloaded or synced. For existing repositories, the index has to be maintained in a separate set of files that takes up extra disk space and I/O.
• For new 1.5 fsfs repositories, there is a new sharding mechanism for storing revisions on disk. Instead of storing all revisions in one single directory, they are now spread across multiple directories which will be better on certain filesystems.  There is a Python script you can run to shard an exising fsfs repository though.
4. If you were using an earlier version of the 1.5 binaries, note that the on-disk format of the repository has been changed in the most recent builds. You should dump your repository with your current binaries, then install the new binaries, create a new repository and load the repository.

Please take the opportunity to give these beta versions on the path to GA a try. Your feedback will lead to a better final release and likely also help us deliver Subversion 1.5 as soon as possible.

The Subversion project has issued an alpha2 release on the path to the final GA. The next release might be alpha3, it might be beta1, that depends on the feedback we get from testers. One thing is certain, and that is the sooner we can find any remaining bugs, the sooner the GA release will be available.  Likewise, hearing that you have used this version with some success will also help us make decisions.

CollabNet has created binaries for Linux and Windows (with OS X coming soon) from this alpha2. You can download them from openCollabNet. There are also updated versions of the CollabNet Merge Client, Subclipse and TortoiseSVN available on this site.

We have a forum where you can post questions, comments or problems that you encounter using this version. If after some discussion a report is indeed deemed a defect, we forward the bug to the Subversion community using their normal processes. Feedback on the GUI merge clients will go to CollabNet Engineering.

A few things to be aware of:

• Subversion 1.5 client has an updated working copy format.  Once an SVN 1.5 client updates a working copy it will be converted to the new format. This means that older SVN clients will no longer be able to read these working copies. So either be careful, or be sure to update all your clients to the same version. There is a Python script that you can use to downgrade your working copy to the 1.4 format.
• Subversion 1.5 server can be used to serve an existing repository, but you will not be able to use the new merge tracking features with this repository until it is upgraded. You have a few options here:
1. Dump existing repository, then create a new repository using the 1.5 binaries and load the dump file.
2. Create a new repository using 1.5 binaries and use svnsync 1.5 binary to transfer the contents to the new repository.
3. Run a new command svnadmin upgrade to upgrade an existing repository. This runs fast as it just updates the internal repository format. There are some downsides to this approach though:
• SVN 1.5 repositories maintain a new index called the node-origins index  This is needed to speed up certain merge operations. The index will be lazy-populated on upgraded repositories, but can be updated on demand by running a new tool named svn-populate-node-origins-index(.exe). If you have a large repository you will likely want to populate the index. New repositories, or ones that are dumped/loaded or svnsync'ed will not need this.
• For fsfs repositories, the node-origins index will be slightly faster and take up less disk space if the repository is reloaded or synced. For existing repositories, the index has to be maintained in a separate set of files that takes up extra disk space and I/O.
• For new 1.5 fsfs repositories, there is a new sharding mechanism for storing revisions on disk. Instead of storing all revisions in one single directory, they are now spread across multiple directories which will be better on certain filesystems.  There is a Python script you can run to shard an exising fsfs repository though.
4. If you were using an earlier version of the 1.5 binaries, note that the on-disk format of the repository has been changed in the most recent builds. You should dump your repository with your current binaries, then install the new binaries, create a new repository and load the repository.

Please take the opportunity to give these alpha versions on the path to GA a try. Your feedback will lead to a better final release and likely also help us deliver Subversion 1.5 as soon as possible.

CollabNet is conducting a short Subversion survey, asking questions about new functionality you would like to see, your deployment of Subversion and support you need (whether it is technical, or to convince management that your company should standardize on Subversion).

Take the Subversion Survey.