Let me first start off by saying how great it feels to be genuinely “busy”. I’m talking about the “excited-and-can’t-wait-to-get-started-or-get-finished” type of busy. I’m slowly finding out that the days are flying by with me barely noticing. Each morning, I’m looking forward to getting to work (yes, even Mondays). So either I’m strange or have found something I truly love doing :). Anyway, I don’t have any technical insights for this week’s post, just more of a status update on something I’ve been tinkering with. Noel of SnappyTouch fame has a similar article about version control, so definitely got check it out to get another (and more experienced) perspective.
The Issues With SVN
As see in some of my previous posts, I use SVN for version control but I figured I’d give an update to my ‘branching’ method. It utterly failed. What’s my current workflow? Branches and merging are much more the exception than the rule right now in my current code base. After a full release of Tilt to Live I’ll branch again to start 1.n+1 but won’t branch for any other issues or experiments. I tried for a while getting SVN to merge things, but I found myself missing files, deleting things that didn’t need to be deleted, and sometimes accidentally working in the wrong branch. Doing an “svn switch” had weird issues where it would sometimes not switch the entire structure but only the root folder I switched from (grrr…).
In any case, branching and merging caused more problems than it solved using SVN. So I went to the ‘merge only on releases’ approach, but that was riddled with issues as well becomes the changes were so large it would cause all sorts of conflicts. I eventually gave up and just ‘branched’ the branches into tag folders to save the bits that were released. Not a bad method, but not exactly how I wanted to work and SVN was forcing me to do things it’s way.
So I have 2 things I’m looking for in a version control system:
- Painless branching/merging with decent history tracking between branches
- A good GUI client
I kept looking into alternatives, and the two that kept cropping up were git and Mercurial. I liked the idea of git, but the problem was no decent GUI support. Both, according to what I’ve read, seem to satisfy the first requirement, so it came down to GUI clients. I’m fully capable of using a command line and willing to as long as it’s and not on Windows or overly tedious, but I still prefer quickly glancing at a GUI to get a sense of what’s going on.
The Experiment With Mercurial
Enter Mercurial. Over the weekend I decided to take mercurial for a spin. And the GUI issue? MacHG seemed up to the task, and is free to try for non-commercial use (donation ware). @SnappyTouch, not sure if you’ve given macHG a look over but it’s definitely seems as robust if not more so than Versions :). I took about 30-40 minutes to go through the quick start guide for mercurial and once I had things down on the command line and understood what the terminology meant, I installed macHG to see if I could use this in a development environment. After a few false starts I was up and running. Surely, mercurial is rather different from SVN since it’s a distributed version control, but from my perspective it worked just the same, if not better than a central one. The biggest bonus was branching (in mercurial it’s usually called cloning) and merging were very painless. It was just as easy as committing changes.
For my test run, I was in the middle of prototyping our next project but wanted to use some framework code to help kick start things. I created a repository with the framework in it, cloned it and started developing the prototype on top of it. As I worked and modified the framework bits I would commit and periodically merge the framework back into ‘main’ repository once I knew it was working and tested. No hassle, no conflicts. To further see if there’d be any pain points, I worked in the ‘main’ repo for a bit of code clean-up while the cloned version was also modified. Still no issue, and it was intuitive as to wtf was merging and changing. As for MacHG, it works very similar to Versions except has full on support for merging, tracking changes, etc. It’s very well done.
The Current Downsides
The downside? It’s a local repository. My SVN repo is hosted with dreamhost so I can get to my code from just about anywhere. But in practice, I have an iMac and no macbook so the only place that code would be useful would be on my iMac. Accessing SVN from multiple machines was crucial a few months ago since I was still transitioning between Windows PC dev and OSX dev, and some of my tools are windows only. But VMWare Fusion and Dropbox solved that issue pretty quickly. If I really need a hosted mercurial solution I may look into Fogcreek’s Kiln since I already use FogBugz. Another downside: doesn’t seem to be any svn:external equivalent. I don’t use it currently for iPhone dev but I did extensively on the PC for shared code bases and such so it’s something I’ll have to try to figure out or look up as I’m sure others have worked around this already.
To Each His Own
If you’re looking to try out a version control alternative, but think ‘git’ is a bit too bleeding edge without a decent GUI client, mercurial seems like a mature and well supported option (particularly on the GUI client front). I’ll definitely be using it for my ‘play area’ and see if it grows on me before I use it on a longer term project. But as is usually the case, it comes down to your own workflow and whether you’re tools are shaping your workflow instead of them helping you get your task done the way you want it to be done.