As a budding Mac developer, one of the things that I’ve had to sort out is which source code version control system I want to use. I first started using version control with RCS some 25 years ago. I’ve introduced version control or better version control at several of the jobs I’ve had. Heck, I’ve even published an article on using version control. Most recently I’ve used Perforce at an installation with a few thousand fellow developers.
Which is to say that while my eyes will still glaze over during a discussion of the relative merits of different delta storage mechanisms, I know enough to know why the latest crop of distributed version control (DVCS) systems are interesting and that I wanted to use one of the “big three” (Git, Mercurial, Bazaar).
I didn’t bother trying Git. Mostly because cross platform support (especially Windows support) didn’t seem to be “job 1″ (or “job 2″ or even “job 3 or 4″) with the developers (understandable given Git’s history but not as useful to me — sooner or later all projects cross platforms it seems). Besides, both Mercurial and Bazaar are largely written in Python which I use extensively and that made them interesting to me. Given that all three are used extensively for large projects, whimsical winnowing criteria like this feel safe enough.
I started out with Bazaar, largely because at the time it was easier to find a non-Fink, non-MacPorts installer for it. It was pretty easy to set up and use and the benefits of it’s distributed nature were readily apparent — my favorite productivity trick is to take my laptop somewhere without a net connection and trivially easy branching and versioning while offline were a breath of fresh air to a Perforce expatriot.
But. I’ve switched to Mercurial. Mercurial now has a non-Fink, non-MacPorts installer as well (maybe it always has). And it has “hg serve”. The “hg serve” command starts an ad-hoc web server that you can browse to locally or over a network to get a quick graphical view of your repository. It comes built-in with Mercurial and it works anywhere Mercurial works. Nothing else to install, no half baked GUI clients, just a good, easy to use GUI. It’s not a particularly functional UI (you don’t use it to check things in for example) but it provides the thing I want most from a VCS UI: the ability to quickly and easy browse through my repository and look at differences between revisions of code. I keep my own code and any third party code I use under source control and the ability to easily look at revisions (color hilighted, full context etc.) is an important aspect of code archeology. Life’s too damn short to spend it looking at raw diffs in a terminal window.
So that’s why I decided to give Mercurial a try. I wound up sticking with it (at least so far) becuase it was relatively easy to find information (mostly on the Mercurial wiki) on how to use Mercurial on a Mac, in particular it turned out to be very easy to confgure Mercurial to use FileMerge for diffs and, more importantly, merges (I’ve never been very good at textual merges with the “>>>>” token markers).
Beyond that, using “bzr” or “hg” commands is largely the same with some minor translation required. In the end, though, it was just easier to make Mercurial dovetail with my Mac and my style quickly and with very little fuss.
The rest of this post will describe how I’ve set up Mercurial. It’s quite possible that all of the following can be done with Bazaar and Git just as easily. I’m putting it here so that it will hopefully will save some one who wants to try Mercurial on the Mac some time.
Once you’ve installed the lastest version of Mercurial on your Mac you’ll want to configure it. You’ll do this by creating and editing an ~/.hgrc file. Here are the contents of mine:
[ui]
username = Keith Fieldhouse <keith@rex…>[extensions]
hgext.extdiff =[extdiff]
cmd.opendiff = opendiff-w[merge-tools]
filemerge.executable = opendiff-w
filemerge.args = $local $other -ancestor $base -merge $output
The “username” in the [ui] section simply provides a nice username to label changes in your repository with. the “hgext.extdiff =” line simply turns on the “External Diff” extension. While it’s labeled an “extension”, it comes as part of the Mercurial distribution. The “cmd.opendiff” line tells Mercurial to run the opendiff-w script (see below) when the “hg opendiff” command is used. Simillarly, the commands under [merge-tools] tells Mercurial how to run the same opendiff-w script when it wants to allow you to do a merge.
The opendiff-w script simply runs opendiff (the command line command that starts FileMerge) through a pipe so that it will wait until FileMerge has exited before returning from the command which is the behavior that Mercurial expects from the diff and merge tools. My copy of opendiff-w is kept in /usr/local/bin and looks like this:
#!/bin/sh
opendiff “$@” | cat
Note that all of the above works after installing the Mac OS X version of Mercurial. No further software is required (well, beyond the Mac developer tools themselves). Most of this information can be found at the Mercurial Wiki. This page and this page describe using FileMerge as a diff tool and a merge tool respectively.
Update: For completeness, here is the “.hgignore” file that I typically use:
syntax: glob
.DS_Store
*.swp
*~.nibbuild
*.pbxuser
*.perspective
*.perspectivev3
Post a Comment