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.
 

New Subversion 1.4.6 Universal binaries for Mac OS X are now available for download from openCollabNet.  Compared to my 1.4.4 release, there are some changes based on feedback from users worth mentioning:

Project Packaging

The package of the binary has changed. The 1.4.4 release installed everything in /usr/local which made the package difficult to uninstall. The 1.4.6+ package installs Subversion into /opt/subversion for easy management and coexistence with other installations. The 1.4.4 packaging also included unnecessary files like header files. While my intentions were good, the delivery wasn't and I removed all developer-centric files from the binary. The reason for this is two fold: It makes life easier for Subversion developers and it makes the package smaller. These changes do not impact the functionality of the binary.

Previous Package Backups

When packaging a binary, many things come into play when it comes to installation.  Do I overwrite existing artifacts with my own?  Do I remove previous artifacts? Etc. The 1.4.6+ installer installs Subversion in a non-destructive fashion. The idea is to make the existing environment ideal for installation while allowing for easy rollback of the installation.  That said, the 1.4.6+ installer "backs up" any existing Subversion installations found in /usr/local and /opt/subversion to a documented location allowing for an easy way to keep old installations around for whatever the reason may be.

Other than these two items, the binary delivers the same great taste as before.  For those of you that didn't install the previous package, here is a short summary of all features of this installer:

• Installation is a fully-featured Subversion 1.4.6 installation
• Installation is Universal so you can run on any OSX-supported architecture (Intel and PPC)
• Installation includes both repository data stores (Berkeley DB and FSFS)
• Installation includes all repository network access layers (DAV and SVN)
• Installation includes all language bindings maintained by the Subversion project (Java, Perl, Python and Ruby)
• Installation includes Apache server modules (2.2.x)

As with previous releases of this binary, the svnbinaries project on openCollabNet is the place for feedback, bugs and questions. 

Special thanks go to pr3d4t0r for helping with testing and pakacging on an Intel-Mac.

P.S. - There are many of you requesting Subversion 1.5.0 beta builds for OSX.  Now that I have the 1.4.6 binary out of the way, I will work on getting 1.5.0 beta binaries out within the next week or so.