I’m launching a new Django-based project at work. I’ll initially be the sole developer, but I expect it to grow to 10 heads (developers, QA, web designers, operations, and project management) over time. I hope to start the ball rolling this week, and one of my first decisions is the Source Code Management (SCM) tool.
Here’s the development environment:
- Up to 12 people using the pool. Four to five of them will be full-time developers. The developers, QA, and web designers will use Macs; operations and project management will probably use Macs but might use Windows
- Most of us will be in the same office space, and all of us will be in the same building. But, I don’t want a tool that obviates our potentially hiring a contractor in a far-away land
- We’ll use the standard pool organization of one trunk with multiple branches
- This is for a commercial product that’ll have, eh, many lines of code. Python will be the major language, and most of the technologies will be open-source. There won’t be a line of .NET, or any other Microsoft technology, within 500 miles of the project
- Perferably open-source. Preferably free
I quickly narrowed the solution set down to Subversion, Mercurial, and Git. I’ve extensively used Subversion, and occasionally used Mercurial.
I first eliminated Git, after reading multiple commentaries about its UI, and getting the sense that it’s less-than-fully baked.
Mercurial’s primary advantages are in minimizing network latency effects, a simple setup, and no status directories (e.g., “.svn”) “polluting” the pool. But, we’ll all be on a high-speed internal network, I’ve used Subversion before and don’t think the setup is terrible, and the declining cost of disk space makes .svn directories a non-issue. These all blunted Mercurial’s presumed advantages.
Additionally, I think distributed SCMs like Mercurial have a not-yet-fully-appreciated problem in making it too easy to not [ever] check code back into the main pool. With a local repository, a developer can feel protected from accidents and continue working happily for quite a long time. And then, say a year down the road, he/she does a massive check-in and discovers an integration problem. Branches, or a local repository that is effectively a private branch, should be easy to make — but not too easy.
Mercurial will be very effective for SCMing individual scripts and one-off files in random directories. It means remembering which files are in Mercurial (or doing “hg status” a lot), but that’s balanced against not needing to make a new repository for a directory that contains just one SCM’d file.
So, I decided upon Subversion, via Trac, for the main code pool, and Mercurial for a “one-off” script SCM tool. Another nice aspect of Subversion is its Trace integration. (Trac has a Mercurial plug-in, but it’s experimental. No thanks.)
References 3 Items:
- Click to Read


