VisualSVN

Back Story

Recently, I set up a media wiki installation. The surrounding requirements were such that I was forced to use a Windows 2003 server instead of Linux, which would have been my preference, but hey, when life gives you lemons, turn the lemon into a WAMP stack. And that’s just what I did. The installs for Apache, PHP, and MySQL went quite smoothly in spite of having to use Windows, and I was up and running with Mediawiki in no time. As an aside, I should note that I tried out a handful of “all in one” WAMP stack offerings and none of them really seemed to work very well. Doing it by hand actually turned out to suit my needs best.

I should also point out that I don’t really have anything against Windows OS at all–I just prefer Linux when it comes to servers. Less overhead, easier security, and more bang for your RAM/processor buck. And I also prefer not to have constraints imposed on me, but c’est la vie.

So with my new Mediawiki install in place on the WAMP stack, I was thinking about backup schemes. I downloaded and installed MySQL Administrator GUI tool (now EOL’ed in favor of MySQL Workbench, which I think needs to get a little more mature and iron out some kinks) and configured an automated weekly backup of the Mediawiki database. Of course, that’s only half the story with Mediawiki–you also need to back up changes you’ve made to the PHP files themselves, where applicable, and any files and images uploaded to the wiki.

My Old Friend, Subversion

For this backup, I decided to go with subversion, reasoning that Tortoise would make it easy for me to see when I had modified files or when people had uploaded things to the wiki. I’d commit periodically, perhaps in conjunction with my automated DB backups, and this would give me a way to completely recreate my Mediawiki install at any point. If I hosted a subversion server on my server machine, I could commit weekly to it locally, and then update from another machine to ensure that I had an offline copy at all times. Perhaps not the most sophisticated backup scheme in the world, but it would get the job done, and I’d have a subversion server as a bonus.

With a New Twist

So when I went to download a subversion install for my Windows server, I stumbled on VisualSVN. Curious, I read about it a bit and decided to give it a whirl. I downloaded the MSI and installed it locally. I could not have been more pleased with the results. I use a subversion server at home on a Fedora server, and when I set that up, I had to mess around with configuring Apache and do something or another with security certificates, if I recall correctly. It’s been a few years, but I remember it being something of a hassle.

VisualSVN ran me through a wizard, and I was up and running with a password protected, directory-level-configurable subversion server that used secure HTTP. It was literally that simple. Already pleased, I saw that there were two main modes of security–subversion and Active Directory. Subversion was default, and it required me to create users and assign them passwords.

At first, this is what I went with, but I was a little put off to learn that the users wouldn’t be able to change the initial passwords that I assigned them. I was, however, pleased to find that I could control with the finest granularity which users had access to which directories. So I set off in search of a scheme that would allow users to change their own passwords. I switched to the Active Directory setting and started to play with it. What I discovered was that it was a snap to setup users needing to login with their own Windows Domain credentials.

So, viola! I didn’t need to create accounts or assign passwords and ask users to change them. They were already synced up with their own logins. From here, I was able to keep the same granularity by adding users in from the domain rather than manually. As setups went, I had a pretty slick one in about fifteen minutes for subversion.

The only drawback, as I see it, is that users can cache their domain passwords locally so as not to have to supply credentials for every SVN operation that they do. The drawback isn’t that they aren’t queried each time, which would be annoying, but rather that they can store their passwords. Of course, the passwords are encrypted by virtue of the HTTPS protocol, so this is really a small nitpick, and I really see no good way around it short of annoying the repository’s users. Not to mention, other applications like MS Outlook and web browsers offer the same kind of local storage, so it isn’t as if I’m doing something unprecedented.

So, if you get a chance, I highly recommend checking out this tool. The version I installed is a free one, though there is a fairly reasonable enterprise edition that gets you some more bells and whistles (if I recall correctly, it uses your current login credentials instead of a user/pass challenge). I might go to that later if the SVN install gains some traction and users like it.