Given the number of developers using Subversion, I'm surprised that no one on my blogroll has mentioned the new Subversion clients released in the last few weeks. Subversion, TortoiseSVN, and VisualSVN have all synchronized their version numbers on v1.5. I'll talk about TortoiseSVN and Subversion changes. VisualSVN has some minor enhancements that basically expose the features introduced by Subversion 1.5. I'll leave you to investigate them yourself.

TortoiseSVN

Let's talk TortoiseSVN... You can get the new client from here. N.B. If you're running 64-bit Windows (XP, Vista, or Server 2003/2008), make sure you grab the 64-bit installer. Shell extensions run directly inside Windows Explorer, which on 64-bit Windows is a 64-bit process. So you don't get any WoW (Windows-on-Windows) goodness that allows 32-bit executables to run on 64-bit Windows.

New Overlays

The most noticeable change is the new overlay icons.

Unversioned and ignored files now have their own overlays, which I find especially useful.  The problem in the past was that Windows only has 12 overlay slots available.  These slots could be easily exhausted if you had multiple shell extensions installed, such as TortoiseSVN and TortoiseCVS.  Tortoise clients now have a common overlay handler, which somewhat mitigates this problem.

Delete Unversioned Files

Over time, working copies tend to get crufty - at least mine do. I end up having extra unversioned files and directories - from tools, builds, half-implemented refactorings that you think better of - littering your working copy. Every once in awhile, I would just grab a clean working copy and delete the old. I then went to the trouble of creating PowerShell script to clean up my working copy. Now TortoiseSVN 1.5 includes this feature. Simply SHIFT-right click in your working copy and select "Delete unversioned items" from the context menu.  N.B. This option only appears if you hold down SHIFT.

Other Improvements

The repository browser has also been completely reworked.  It now shows a two pane view similar to Windows Explorer.

The revision graph has also been rewritten and is much easier to use.

Client-side caching has been improved, making TortoiseSVN more responsive. Merging has improved. Changelists have been added. Lots of new features. You can read the release notes for more information.

Subversion

Subversion has made a lot improvements, which can be found in the release notes. If you're just running TortoiseSVN, you don't need to install the Subversion binaries. TortoiseSVN includes the SVN libraries. You only need the Subversion client and/or server if:

1. You want to use Subversion from the command line via svn.exe and/or svnadmin.exe either directly or in scripts.
2. You are running a server using svnserve (svn://) or Apache (http:// or https://).

You can download the Windows client and/or server from a few different places, each with advantages and disadvantages:

• CollabNet - On the positive side, the MSI installer is quick to get you up and running. It adds svn.exe to your path and, if you install the server, you can select between svnserve.exe (svn://) and Apache (http:// or https://) easily. On the downside, you have to register on the CollabNet site and the downloaded binaries do not include support for Berkley DB, only FSFS. FSFS is the default for new repositories, but if you've got some older repositories around, they're probably BDB. The CollabNet binaries complain bitterly about BDB repositories: "svnadmin: Failed to load module for FS type 'bdb'". Honestly I would recommend staying away from this package.
• Tigris - Scroll down to svn-win32-1.5.0.zip and grab that. It includes both FSFS and BDB support, but you're on your own configuring svnserve.exe. It's not that hard and I document the steps here. This package is great if you just want to run svnserve.exe to access your repositories via svn://. If you want to run Apache to enable access your repositories over http:// and https://, you're on your own to download and configure Apache. If you want to do that, then I recommend...
• VisualSVN Server - Although VisualSVN (the Visual Studio add-in) is a commercial product, VisualSVN Server is completely free. This is the easiest way to get a Subversion server up and running with Apache. You can go from a clean Windows box to a working Subversion server in under 10 minutes. As an added bonus, it includes a MMC management console.

Upgrading the Repository Format (optional)

Although Subversion 1.5 can work with older repository formats, some of the new features, such as merge tracking, require you to upgrade your repository to the latest format. (See "Compatbility Concerns" in the release notes for full information regarding required client, server, and repository versions for various features.) Subversion will not upgrade your repository automatically. If you want to use the new features requiring a repository upgrade, you must run the following command:

svnadmin upgrade <PATH_TO_REPO>

where <PATH_TO_REPO> is the physical path and not a URL.

If you need to upgrade a lot of repositories and you've got PowerShell installed, you can do the following (assuming your repository root is c:\SrcRepos):

cd \SrcRepos
dir -name | foreach { svnadmin upgrade $_ }

Cyrus SASL and NTLM

TortoiseSVN and svnserve now include Cyrus SASL (Simple Authentication and Security Layer) support, which allows you to use a variety of authentication/encryption mechanisms, most importantly for Windows users - NTLM and Kerberos. Subversion clients and servers prior to 1.5 only support ANONYMOUS and CRAM-MD5. You'll need to be running v1.5 on both sides of the wire to use the other protocols. The ZIP package from Tigris includes NTLM, but not Kerberos. If you want to use Kerberos, you'll have to download saslGSSAPI.dll and add it to your sasl-plugins directory.

WARNING: I spent the better part of an afternoon trying to get svnserve.exe authenticating against the local Security Account Metabase (SAM) without success. (i.e. Using local Windows accounts to authenticate Subversion users.) The documentation is sparse to non-existent. I was able to get SASL to read its configuration and load the NTLM plug-in, but I could never successfully authenticate. Even with the correct username/password, it just prompted me again. It could be a problem with SASL defaulting to NTLMv1, which Vista disables by default for security reasons. If I figure out how to make this work, I'll post a solution...