Version control systems for Mac OS X
This document was originally written in late 2003 / early 2004. The scene has changed some in the meanwhile, with various offshoots of Arch and Subversion gaining a lot of mindshare, and some of the URLs are probably now invalid. However, the broad conclusions still hold, and this is left here for informative value.
In the world of the amateur programmer (and often that of the scientific programmer), version control systems / revision control / source code management are usually neglected or left in the "we'll do that sometime" basket. The arguments for using some form of code control have been expounded upon at length by wiser heads than my own. So I'll just say this:
Use some form of source code management. Even if it's just saving a copy of your development folder weekly. Eventually, there will be a disaster and you will need that backup.
With the advent of OS X, a whole bunch of VCS tools have made their way to the Macintosh. Below are a few very brief notes on the systems that I've tried, put here for the general use. Some other resources on this topic are:
- Macintosh Version Control: a survey of available systems by someone who should know (a VCS developer), that is far more detailed than these notes. My only complaint is that it tends to concentrate on the graphical systems and doesn't mention some of the newer commandline tools (Bitkeeper, Arx etc.)
- Version Control and the Single Developer: an older article by the same author as above, but chattier about the whole subject of version control.
- Version Control Systems: the next generation: a lengthy and spirited discussion on many of the Unix VCS tools.
- Revision Control: a Wiki encyclopedia entry on the VCS in general.
- Designing a New Version Control System: ... and in the process critiquing every system that already exists.
- Source Control: Not Just for the Big Boys: MacSlash weighs in with its two cents worth, why you need VCS and what the pros and cons of the various systems are.
CVS (Concurrent Versions System)
The defacto standard for version control, CVS has near-universal use in the Unix world. It's been ported to just about everywhere, and exists in commandline and graphical versions, with many associated tools. It's free and has been used for massive projects. Project Builder interfaces directly with CVS.
Having said that, I can't recommend using it. The whole system badly needs overhauling, it doesn't do atomic transactions or cope well with binary files. [unadorned opinion] I find CVS archaic, restrictive and frustratingly opaque. [/unadorned opinion]
- Mac OS X: Version Control with CVS: some notes from Apple.
Perforce is a commercial product but there is a free two-user demo for non-commercial developers. That last restriction has prevented me from a more than cursory examination of the product, but Perforce has lots of fans, is cross platform, has commandline and web interfaces, is fast and safe.
This has won a lot of fans but if you google for opinions on Bitkeeper, you'll end up with a lot of pages ranting on about how the Linux kernel development team shouldn't be using it, due to some admittedly strange licensing terms. [deep sigh] Still, if it's good enough for the Linux people, it's probably worth checking out. It's available for free with some minor restrictions and has a lot of nice features.
The Mac OS X download for Bitkeeper comes as a .bin file that no dearchiving software wants to know about. Go to the commandline, change the name of the file and make it executable before running it. You also have to explicitly say where you want the executable installed:
downloads> mv bk-301-macosx-ppc.bin bk downloads> chmod +x bk downloads> ./bk [... installation ensues ...]
VOODOO is a well crafted, award-winning, commercial, GUI tool available in standalone and server versions, but only on the Macintosh. I ponied up the price for this a few years ago and used it for 6 months before moving on. It is a very good and robust product and undoubtably a lot of people will find it's just what they need. But ...
... but I found it a bit too powerful and overwhelming for my own needs. The Mac-only aspect was a bit of a problem and I tangled repeatedly with the CodeWarrior plugin. You can set up CodeWarrior so that when you open a project, it checks all the necessary files out from VOODOO. However, you have to explicitly check them back in. Which means that if you close the project without checking the files back in or have a crash [you can see this coming, right?] ... when you next open the project, VOODOO overwrites all the files you changed. Whimper.
Subversion is an ambitious project aimed at correcting all the perceived problems with CVS and building a fully. Despite it's seemingly perpetually low version number, it is quite functional and has a lot of fans. It has a converter for CVS repositories, is designed to work over the Internet
Unfortunately, to set up or host a Subversion repository, you have to setup your Apache webserver. As far as I'm concerned, setting up webservers is one of those TTIPOPTD (Things I Pay Other People To Do). Tom Lord (who designed Arch) has also expressed severe reservations about the direction of the Subversion project. This was therefore a no-go.
(A posting on Slashdot asserted that you didn't need Apache to run Subversion. My reading of the FAQ said otherwise and if I was wrong, so much the better.)
Arch , ArX etc.
Arch is a simple, light-weight VCS that's easy to learn and features distributed repositories and easy branching. It's what I've settled on for the moment as it seemed to be just powerful enough for my needs and no more. It's got a lot of complimentry press. At some point Arch forked and spawned another version, ArX, although there's little to pick between the two versions to my eye. There are also a number of more offbeat implementations.
Written in some bizarre concoction of languages, against all expectations Arch works. One must pay close attention to the installation instructions however, for they must be followed to the letter otherwise strange errors messages are eventually produced. (Eventually - otherwise it would be easy to know what's gone wrong.) Even then, the test suite generates some errors. Despite these, it will install and run nicely. Just for reference, the steps I used for ArX-1.0pre7 are below. However, the accompanying documentation should always take precedence:
% cd ArX-1.0pre7 % cd src % mkdir =build % cd =build % ../configure --prefix ~/bin/ [...] % make CFLAGS=-no-cpp-precomp CXX=c++ % make [...] % make test [...] % make install [...]