I saw an interesting post over in the XNA Forums about team based development and I decided to share some of my experiences doing exactly that at Funavision. As I was writing my reply it dawned on me that this is probably a significant stumbling block for a lot of start-up Indie game developers. So I've decided to make this post and share my experience with a broader audience.

In this post I'll cover what we've done for distributed development over at Funavision as well as give some tips and tricks we've picked up that will help you out. The focus will be on Version Control and Project Management tools with a strong emphasis on free (as in no cost) and Open Source tools. It will also be heavily skewed towards XNA and Windows development (largely because if you're, say, a Linux developer then you likely know most of this stuff :-)

The post will be linked from the XNA Forums. Hopefully that will get it around enough people who need it that word of mouth can then take over and the people who could actually use this information will be able to find it.

I do want to say that what we did at Funavision is by no means the end-all, be-all solution for working in a distributed team-based way. There are many different ways to accomplish what we've done, and many different technologies and techniques that can be used (both open-source and proprietary). All I can say is that this is how we've done it, and it's worked very well for us. If you're someone lost and looking for some options, then you certainly could do a lot worse than what I'll be describing. However, if you already have something that is working well for you then I'm not suggesting you should ditch it and try the solutions described here. Each to their own.

Link to the release notes. Reprinted here...

Go get it!

Mercurial 0.9.4 is available for download at:

 http://selenic.com/mercurial/release

New features:
 * support for symlinks
 * improved tag handling
 * improved merge handling of file and directory renames
 * improved named branch usability
 * numerous improvements to commands
 * generic pre- and post-command hooks
 * improved Windows support
 * basic BeOS and OpenVMS support
 * numerous bug fixes

New extensions and contributions:
 * extensions can now be specified in .hg/hgrc
 * new convert extension with CVS support
 * new graphlog extension
 * improved patchbomb extension
 * example FastCGI script

Source

When it's all said and done, you should have a working Hg repository server and should be able to pull/push from/to it.

Setting up the Hg http interface

As I said before, I used SVN via WebDAV and it was pretty painless once I got it going. Thus, I want Hg to behave exactly the same way when I do my pushes and pulls. Hg doesn't use WebDAV (at least, if it does, I didn't look deep enough into the documentation to figure out how to set it up), but it does come with a handy CGI script for giving you the same basic functionality.

Configuring hgwebdir.cgi

Converting single/multiple SVN repos to Hg repos

As I said in my last entry, I've been evaluating the various modern DVCSes to try and figure out which of them would give me the most benefit, while at the same time irritate me the least.

I've been using Subversion (SVN) for a few years now on my dev servers (formerly, svn.samhart.net and friends) and have mostly been pleased with it. In fact, the only reason I even considered replacing SVN was because there were certain aspects of DVCS that I felt could make my life easier, namely the ability to have a repo's entire history available locally and the fact that offline work can be done so much easier with them.

Additionally, I've been working with a lot of modern DVCSes lately (namely bzr, git and svk) and I've been very displeased by each of them. They all had at least one critical problem that, for me, made them impractical to even consider for use in my own repos. The end result is that I've spent a lot of time frustratingly researching and testing as many DVCSes as I could to try and figure out if I should switch or just stick with SVN.

But, after the smoke cleared and the fires died down, I discovered that one DVCS, Mercurial (Hg) was left standing on equal ground with SVN in the "has to not irritate me" department.

The problem? Conversion from SVN to Hg isn't as straightforward as one would like. Thus, I'm documenting the steps I had to do to try and help out anyone else who's attempting to go down this path.

Moved to here.

Well, I've been migrating my development server to a new hoster (actually, they aren't new, I've used them for years for my other stuff, and been very pleased with them). In the process of the move, I've been cleaning things up and re-engineering things somewhat to solve some of the problems I've had traditionally.

One of the things that does keep coming up is a question as to whether or not I should continue to use Subversion for my online code repo. So, I've been looking at other alternatives, especially DVCSes, trying to see whether I would get any real benefit from them, or just be more burdened.

What's my conclusion? My conclusion is that they all suck, and maybe I just need to stick with SVN. Read on for the details...