I've been contemplating the move towards a self-hosted Subversion
repository for quite a while. My earlier attempts worked but left me
with a lot of inconvenient and sometimes quirky side effects. These
experiences always led me back to hosting Subversion on Linux, which is
really where it works most naturally. Recently, however, I decided to
retry my luck with Subversion hosting on Windows and I made the call to
go with a "package" instead of doing the Apache / Subversion
integration myself.

The tool that I went with,
VisualSVN, is a
Windows version of Subversion that targets primarily Microsoft
developers using VisualStudio as their development platform. Matter of
fact, the Subversion server package is freely distributed and the
actual product that is sold is the Visual Studio plugin that allows you
to tap into Subversion from Visual Studio. With a 30 day trial period
and $49 price tag, I decided that it couldn't hurt to try it out. My
findings are below:
- VisualSVN Server - The
VisualSVN server, as mentioned earlier is a freely distributed product.
You can get this piece of software whether or not you ultimately decide
to buy and use the Subversion Visual Studio plugin. The server runs
exclusively over HTTP / HTTPS (using OpenSSL) and does not support
Subversion's binary protocol or running Subversion over SSH. Obviously,
this means that Apache is in play. A version of Apache is included in
the distribution. Initial configuration of the server is very easy, the
setup instructions describe the extent of it. As I blogged about
previously, this changes a bit if you try to get Apache and IIS to run
side-by-side. In this case, you need to be very explicit and tell the
very greedy IIS to stop listening on other IP addresses so that port 80
can be shared by IIS and Apache. I included links to the Microsoft
article in my earlier post. In this case, you'll want to use httpcfg delete iplisten -i xxx.xxx.xxx.xxx to stop IIS from listening on the port Apache is running on.
The
folks who designed VisualSVN added some cool management functionality
that shields the administrator from lower level Subversion commands.
Implemented as a Windows MMC snap-in, Subversion repository
administration be performed right alongside other server management
tasks. The MMC enables one step creation of repositories (with or
without the standard Subversion folder structure), creation of users
and groups, and assignment of user privileges to repository actions.
- VisualSVN Visual Studio Plugin - As
useful as the server is, the real product is the VisualStudio plugin.
The most recent version of this plugin works on VisualStudio 2008 so I
thought I'd install it and give it a whirl. Installation is fairly
easy. Both TortoiseSVN and the VisualSVN plugin must be installed. I
don't know exactly how VisualSVN communicates with Tortoise but it seems to
make sense to leverage an existing Windows Subversion library rather
than building everything from scratch. Using both the plugin and
Tortoise gives you two ways to work with Subversion. In my experience
with other Java IDE plugins (Netbeans and Elcipse), this is sometimes
necessary to get around the shortcomings of the browser plugin.
Adding a project to VisualSVN using the
plugin is, as it well should be, a relatively easy task. VisualSVN has
some intelligence built in above and beyond the basicTortoiseSVN
libraries. In my case, the plugin didn't add my Visual Studio settings,
binaries, or a bunch of MP3 and JPEG photos that represent content and
really didn't belong under source control. Other than that, a lot of
the processing is just handed over to TortoiseSVN. The SVN UI presented
by the plugin should all be pretty familiar to you if you've ever used
TortoiseSVN before.
This looks to be my keeper for Subversion hosting. Now I need to port over my existing repositories into the VisualSVN server.