Working with Subversion on Mac OS X
Until very recently I’ve not had the opportunity to totally ditch Windows as a web development platform. I knew that a lot of people had recommended going the whole way to using OS X, and I was relishing the opportunity in my new role. Unfortunately it seems there is one crucial part of the puzzle that is missing for serious web development, and that is a decent version control client for Subversion.
My requirements for what I consider constitutes a ‘decent’ client may not be the same as everyone else’s, but I figure that they’re not too unreasonable given that my general level of expectations has been raised by the quality of every other app I use in my workflow on OS X. So what do I expect?
Not Java-based
There are a couple of cross-platform, Java-based Subversion clients out there (neither of them entirely free), notably SynchroSVN and SmartSVN. I don’t consider a cross-platform application a decent solution; they are always sufficiently platform-agnostic as to ignore basic Human Interface Guidelines for OS X (and probably Windows, too), and they tend to have the classic hallmarks of having been designed by a programmer. Things such as using non-standard command shortcuts and building their own ‘master password’ system into the application, down to something as cosmetically trivial as using Windows-styled icons shouldn’t happen in a properly OS-localised application.
Not integrated into an IDE
A couple of separate suggestions came in to use plugins to IDEs (e.g. Subclipse, or Subversion with Xcode). I’ve already got an editor I like, and I’m not about to change my primary production tool in order to get support from what ought to be an external part of the workflow, nor do I particularly want to run an entire IDE just to make use of one tiny part of its functionality. As it happens, TextMate already has some rudimentary Subversion support, but I don’t want to work on Subversion within my text editor. I’m a firm believer in a modular approach to software tools; each should be very good at the task it’s built for, but be very specifically intended for that task.
Edit: after further discussion with a friend about this specific subject, I thought of a better way of explaining why I disagree with IDE integration. It’s perfectly reasonable to find IDE integration very useful if that is all your workflow encapsulates; if you are exclusively editing source code files with a single editor, then stepping outside of that editor to commit your changes might not make a lot of sense. If, however, you are editing data of a number of different types, then the suggestion of having Subversion integration in each of the editing tools quickly becomes ludicrous; would you expect Photoshop to have Subversion integration? What about a visual CSS editor? This is why I feel it ought to be a separate application.
Interface designed for Human Beings
In a way this is just another symptom of the first requirement, but it seems to exist in other platform-specific Subversion clients for OS X too; in short, interfaces that are excessively complex, expose too much functionality at once (consider which are the actions you need to use repeatedly in a Version Control application) and offload a lot of the burden of responsibility for deciphering the complicated information that a repository or a working copy contain into the lap of the user.
Has a powerful, yet well-designed diff/merge tool
If I’m totally honest, I don’t need a graphical Subversion client for 99% of my interactions with the repository (hence my earlier comments about most-frequently used commands); svn update and svn commit from the command-line are easily what I use the most. However, our development environment here means that a large number of unversioned files sit in the working copy, and remembering to manually add only the specific new files you want to commit can be something of a chore. But this pales into insignificance next to the process of performing a merge or diff from the command-line. I simply don’t think this is something that works well from the command-line.
The biggest irritation with all of these complaints and requirements is that they are all met, and met exceedingly well, by an existing project for Windows: TortoiseSVN. That a Mac OS X equivalent still doesn’t exist (I’ve been using Tortoise for over 3 years) is quite shocking. I’ve discovered today that a new, dedicated Mac OS X client called Versions is in development and due for beta release shortly, although it’s hard to gauge from the single composite screenshot if it’ll meet the needs I’ve listed. Until that day, it seems my best option is to just use Tortoise from within Parallels.