My solution to SVN on the Mac

A couple days ago I wrote about how frustrated I was with the inferior SVN options available for Mac users. While I have great faith in Made By Sofa and anxiously await the beta of Versions, it simply isn’t available. Via the comments on that post, I started to get the impression (as happens from time to time) that I may have been too hasty in my judgment of the clients.

For clarity, it needs to be said that I am (A) a visual person and prefer GUI when I can avoid command line, however powerful it may be (chaz), and (B) I despise “kitchen sink” apps with a dozen panes of conflicting information, file navigations, status messages, etc.

In the past, I’ve been the sole developer on my projects. If and when I was working on code, I never had to worry about overwriting anyone else’s work, or wondering what the latest update was. More often than not, I start locally, building flat files or using MAMP, and then end up in the sandbox on the client server doing live edits (I know, I know, bad practice).

While I’m the lead HTML/CSS guy here at work, I have the CMS team linking to stylesheets, and the JS guy making modifications to templates to init his stuff. Corporate is also a little more anal about losing work. No data stored in a single location, backups, backups, backups.

What I was looking for was a way to:

1. Use Textmate and Finder for file manipulation
2. Commit changes painlessly to the SVN repository
3. Have those files automatically available on my development server with the latest version.

The revelation was realizing that I needed to break down the distinction between local, repository, and dev server into only 2 locations: work and backup. If you haven’t used MacFuse before, it is a free “mechanism” from Google that lets you mount almost any file system on the Mac, including servers via SSH. Using SSHFS, I am able to locally mount the dev server. Then I simply checkout the latest changes to that location (without the need of Capistrano or other recommended tools), and edit via TextEdit as if it were local.

For the client, I ended up using SmartSVN because while feature-ridden (if not bloated), it’s config settings were the “killer feature.” Essentially they “just worked.” While Textmate has an SVN bundle, it requires the configuration of a shell variable that never worked. When SCPlugin actually communicated with the server, it was busy trying to version my entire drive, OS and all. Needless to say, I uninstalled that one but quick. SVNx is cute but completely unusable by shrugging off the naming conventions of SVN for its own (copy = commit? what?) and crashing repeatedly.

I had tried SmartSVN first, at the very beginning, and been turned off because it was very PC-like, the closest thing to a “kitchen sink” app I’ve seen on a Mac in a long time. It came in with very little consideration for UI, and an assumed high level understanding of what you were doing. 3-4 screens for every update, commit, comment, etc. I simply had no idea if I was irreparably damaging the repository while I groped my way around its interface blindly. By the time I had rolled through all those other apps, I was an SVN expert, and ready to tackle SmartSVN. Sure, I should have RTFM, but if you’ve read this blog at all, you know thats just not me.

For extra ease of use, I recommend setting up public keys for the server on your computer so that SSHFS doesn’t ask you for a password everytime you connect. Also, look into the preferences panel to automate updating and as many other tedious steps as possible.

At this point, I’m extremely comfortable with my setup, and so is my team. I find it pretty annoying that SmartSVN versions the .ds_store files, but until I find a way to kill that feature, I’m willing to live with it.

How’s your SVN hunt going?

Side note: I used Zemanta to automate some of link making process in this post. Disappointingly, all I got was some Wikipedia links and pictures that didn’t match. That said, I have faith the service will improve.