As you read this, AnkhSVN is under active development for a 2.0 release scheduled shortly after Subversion 1.5. Things have changed a lot over the last few months in the AnkhSVN world and time has come to begin showing you how AnkhSVN 2.0 will be a better Subversion client for Visual Studio.NET. While we aren't ready for a beta yet (for example, merge support isn't completely finished yet), we are ready to give you access to AnkhSVN 2.0 previews via our daily builds.

The AnkhSVN 2.0 builds are very stable already and provide a great integration between Subversion and Visual Studio 2005/2008. To get an idea of what you can expect from AnkhSVN 2.0, view our roadmap. The roadmap shows the major new features in AnkhSVN 2.0 but other things are included as well: improved usability, general bug fixes, performance enhancements and more.

Please help us with testing our daily builds; we rely on the help of the user community to ensure quality. To report defects, or make suggestions for future enhancements, catch us online in #ankhsvn on irc.freenode.net or visit the community support forum on openCollabNet.

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.

Hopefully you have already read my post from last week, Subversion merge made easy.  In that post, I linked to information on the new CollabNet Merge client that we are building for Subversion 1.5.  There has been a lot of good feedback from users who have downloaded and tried that client.

This week, we are introducing a preview of an extension to the merge client that allows you to perform merges based on change sets.  With this extension to the merge client, users of CollabNet Enterprise Edition's Project Tracker can perform merges by specifying Project Tracker artifacts as the input to the merge process instead of having to specify a list of revisions.  This is a really easy way to perform certain types of merges and can lead to some interesting new workflows and business processes.

If you have already installed the merge client, you can just visit the same installation site and grab the change set extension.  I have also written an overview of the client that has some more details and screenshots.  Click here for the overview of the change set extension.

While you will need Subversion 1.5 on your server to get the full benefits of merge tracking, the bulk of the features of this change set extension can be used today with your version of CollabNet Enterprise Edition.  So give it a try and let us know what you think.

It has been a busy few months for the Subversion engineering team at CollabNet and the Subversion community in general. As we detailed in many posts this summer, the entire team is hard at work on Subversion 1.5, specifically the merge tracking feature. 

Back in the spring we started the Merge Tracking Early Adopter Program on openCollabNet. We wanted to make it as easy as possible to get people to try early versions of the merge tracking code and provide feedback to CollabNet and the Subversion community. The program has been pretty successful and provided some valuable feedback that was incorporated into the merge tracking deliverables for Subversion 1.5. Last week we refreshed the Subversion 1.5 Beta binaries on the merge tracking site to a more recent version in order to spawn a new round of testing. If you have not already downloaded them, please download them and give them a try. It is not too late to help the community deliver the 1.5 release.

The title of this post is "Subversion merge made easy" and that brings me to an announcement of sorts. While all of the work on Subversion 1.5 has been going on, another team at CollabNet has been working on a new GUI merge client for Subversion. Today we are releasing a beta version of this client as part of the Merge Tracking Early Adopter Program. A lot of work went into this client and there are many features. Rather than listing them here, let me instead link to the documentation on the merge tracking site.  The documents explain how to install the client and give an in depth overview of its features. I encourage you to download the client and give it a try. Use the forum of the merge tracking project to provide feedback, ask questions, report problems etc. If you try the client, you will automatically also test the Subversion 1.5 merge tracking feature, which can only help to accelerate its release.

Finally, since we are talking about merge and making it easier, I just want to also mention an upcoming webinar that is being presented by two of my colleagues at CollabNet -- Bob Jenkins and Auke Jilderda. They have both contributed a lot of ideas and feedback to the merge tracking feature as well as assisted in putting together the merge tracking early adopter program on openCollabNet. Their webinar is sure to be stocked with valuable insights on branching and merging in Subversion.

As you probably know, Subversion 1.4.4 was recently released.  I wanted to let you know that the CollabNet Subversion team is hard at work putting together our packages for 1.4.4.  We will release them in a staged order: Linux first, Solaris second and Windows third.  Most of the time and effort in our release process is spent in QA and validation and the reason we do the Linux and Solaris packages first is that we can get those versions in the hands of our QA team the quickest.  Eventually, I plan on making the order Linux, Windows, Solaris, as there are more Windows than Solaris users who are seeking the packages.

The Linux package is in the final stage of our validation process and I expect it to be available on openCollabNet later this week.  The Solaris package should be available next week and Windows the following week.

It’s worth pointing out that the most significant fix in 1.4.4 is a potential (though very unlikely) repository corruption with BDB repositories.  Since CollabNet recommends FSFS and CollabNet Subversion comes pre-configured with that back-end, this BDB fix does not affect CollabNet Subversion users.

We had a really nice addition to the Subversion merge tracking feature committed to trunk last week.  Hyrum Wright is a student participating in the Google Summer of Code program.  He has signed up to provide "Merge Auditing" features for merge tracking.  You can see some details on what this means in the functional specifications, but essentially it is about adding intelligence and awareness of the merge tracking information to the svn log and blame output.  In the merge tracking planning, this has been slated as a post-1.5 feature.  It is a feature everyone really wants to see in the code-base, but it was just felt that shipping the release and the core functionality had to be the priority.

Anyway, in this case it appears we will be able to have our cake and eat it too.  Hyrum, whom I should add is already a full Subversion committer, has made great progress on adding this support to the svn log command and has committed those changes to trunk.  Additionally, it turns out that the sample repository we created for our Merge Tracking Early Adopter program really helped to work out the kinks in this feature.  Since we had a nicely documented sample repository, and matching graphic, that Hyrum could refer to, it made it easier for him to refine the feature and get it working properly.

The above picture is the history of our sample repository. If you take a close look, the r14 commit to trunk is an interesting example where this feature comes into play.  This commit is a merge from a branch, and the merge also contains additional merges from another branch.  If I run this command (note the new -g option):

svn log -g -r 14 $REPOS/trunk

Here is the new output:

------------------------------------------------------------------------
r14 | merger | 2007-05-30 15:48:11 -0400 (Wed, 30 May 2007) | 3 lines

Merge branch b - product roadmap and update about page

Command executed: svn merge $REPOS/branches/b
------------------------------------------------------------------------
r13 | buser | 2007-05-30 15:46:48 -0400 (Wed, 30 May 2007) | 1 line
Result of a merge from: r14

Update info about our company
------------------------------------------------------------------------
r12 | merger | 2007-05-30 15:45:19 -0400 (Wed, 30 May 2007) | 3 lines
Result of a merge from: r14

Merge branch a - product roadmap

Command executed: svn merge $REPOS/branches/a
------------------------------------------------------------------------
r11 | auser | 2007-05-30 15:43:00 -0400 (Wed, 30 May 2007) | 1 line
Result of a merge from: r14, r12

Add product roadmap
------------------------------------------------------------------------

Note how it includes information on the revisions that were merged in r14, and additionally how one of those revisions was the result of another merge.  Graphical clients like our CollabNet Desktop - Eclipse Edition and TortoiseSVN should be able to do really useful and interesting presentations of this information in their UI.

This is fantastic work Hyrum.  Keep it up.  I cannot wait to see the blame implementation come together.

Note added on June 11th: we now have Subversion 1.4.4 binaries for Mac OS X, read more in Jeremy's blog post.

You love Subversion and you love your Mac. But where do you get your command line client? I had that problem too and I'm very happy to announce the availability of a new Subversion 1.4.3 binary for the Mac OS X operating system. You can download it right here from openCollabNet. Within the next few weeks it will become part of a community project that will have as its goal to provide up-to-date Subversion binaries for many operating systems.  We’ll blog about it when that project starts but let’s learn about the Mac OS X binary first.

The new OS X binary is a complete Subversion 1.4.3 command line client installation. Using the Mac graphical installer, you can install the binary on any 10.4.x OS X operating system. The binary is "universal" so it runs on both the Intel and PPC based systems. The binary contains the Subversion executables and all necessary/dependency headers and shared libraries. This means that you can compile other applications against the included libraries, for instance to compile Apache to throw a network layer onto the newly installed Subversion binary. The package also includes the JavaHL bindings for those of you using Subversion natively from a Java application, like the popular Subclipse plug-in for Eclipse. 

While this Subversion binary is fully functional, this is only the beginning. With a community project surrounding the efforts required to build this binary, we can eventually include more bindings, better packaging and possibly a Subversion server for Mac OS X. The sky is the limit and our community will be the steward of what is to come. Expect more information about the community project in the near future.

If you have been reading this blog, then you know that we recently held a webinar on Subversion in the Enterprise. The attendance at this webinar was amazing and we received a lot of questions from attendees during the webinar. I was assigned to answer the questions that related to Subversion tools, since that is my particular area of expertise. So, without further ado...

Does Subversion have a source file differencing tool? Can a third-party differencing tool be supported?

Yes and yes. Subversion includes the diff command. The only limitation it has is that it will only work on files that are managed by Subversion. You cannot use it to difference two arbitrary files, it has to be files within Subversion. However, you can also use it to produce all the differences between two branches or the current trunk and a tag, or just the changes you have made locally in your working copy. The svn diff command can also launch a third-party diff tool if you have one that you prefer. Finally, the Subversion graphical clients I have used (Subclipse, TortoiseSVN etc.) include a graphical diff tool and can also be configured to work with external tools.

I had a recent post about the diff command on this blog.  You might take a look at that post to see some examples of how diff can be used and the syntax of the command.

Can you recommend a Web-based client tool for Subversion?  TortoiseSVN is great, but it requires us to load software on the user's desktop.

I assume you are talking about an actual web-based Subversion client. I am not aware of any that exist, although I have seen people express interest in writing one. So it is possible there are some that exist in some state of development. The truth is that it would be a difficult task to write a good web based client. You would have to recreate all of the Subversion features in the web client and then somehow implement those features on behalf of the user on the web server.

Does CollabNet offer anything to help integrate Subversion with a development environment such as Eclipse?

I am one of the project owners of the Subclipse project which provides support for Subversion inside of Eclipse. The Subclipse team (specifically me) works closely with the Subversion developers to help define the features and API we need to develop a good Eclipse client. There will be a number of enhancements to Subversion coming in the 1.5 release which were specifically added at the request of the Subclipse team and our needs. Of course these enhancement benefit everyone, but we helped define the "itch" so that the developers would "scratch" it.

What clients would you recommend for Eclipse and also Visual Studio?

As a project owner for Subclipse, I would obviously recommend Subclipse for Eclipse. Subclipse has been around for several years and is a mature product that implements all of Subversion's features and has a strong user community. On the Visual Studio side, I would look at two tools. AnkhSVN is an open source project that provides support for Visual Studio 2003 and later. I have heard lots of positive comments from people that use it.

VisualSVN is a somewhat recent entry on the commercial side. I think what they are doing is interesting and the price is very reasonable. They have taken the approach of building their client on top of TortoiseSVN which I think is a great idea because it gets them access to a very full featured user interface and lets them focus on adding the value that is needed to make a good Visual Studio integration.

I do not develop in Visual Studio, so I have never used either product.

Which Eclipse plug-ins support refactoring through the Eclipse context menus?

Subclipse has always supported refactoring within Eclipse. If you perform a refactoring operation that renames/moves a file, Subclipse sees this happening, intercepts the operation and performs it using Subversion so that Subversion knows about it. There are some limitations in Subversion itself that might give the perception that Subclipse does not support refactoring.

1. Subversion does not allow a file/folder to be renamed/moved twice without a commit in between. Subversion trunk code has been enhanced to remove this limitation, so it will be available when 1.5 is released. Subclipse refactoring support will be a lot better because of this change. I have already made the changes in Subclipse to leverage this Subversion change and refactoring now works really nicely. That being said, refactoring works nicely today if you are aware of the limitations and can work around them.
2. Subversion's support for move/rename has some limitations that can effect you when doing an update or merge. You can see a detailed explanation in this post on my personal blog. A short explanation is simply that if you have made some changes to a file, and someone else renames the file and commits the rename, when you do an update, Subversion does not transfer your changes to the renamed file. Subversion is smart enough to not delete the local file with your changes, so you can at least copy them over to the new file manually. Ideally, it would do this for you. The Subversion developers recognize the need to make this improvement, so hopefully it will come in a future release. It is a difficult problem for them to solve and is not planned for the next release (1.5).