Jeff On Games

So, as I said earlier, one of the great things about working at Orbus is that, not only do I do more at the company, I’m free to talk about what I do more. A lot of the technical setup of everything at Orbus (including the workflow) fell on my shoulders, and I took what I’d been reading and learning from various blogs and websites to heart, trying to create a workflow that would give us both development speed and code safety. This was why I was so enamored with the concept of the “user branch” when I came across it several months ago.

User branches are a fine concept, in theory anyway. Everyone develops on their own branch of the project, occasionally merging the trunk into their branches to get up to date code, and occasionally merging their code into the trunk once they’re happy with local changes. This has several advantages:

1. If developers are working on a very complex feature, they don’t have to worry about changes from other developers breaking (or interrupting) their work.
2. Developers can check in as much as they want without being afraid of breaking other user’s builds, which means that they can keep a history all the time. On a centralized, fault tolerant server (as opposed to their local box).
3. Small collections of changes can be reserved for review on the branch. A simple tool could easily compare a branch to the trunk for relevant changes for code review, and make the whole process easier.

Those of you familiar with distributed source control systems (like Darcs and Git) already know most of these benefits, but the problem I had with these systems, aside from the lack of Visual Studio and Windows support, is they didn’t address the second point.. I like to try to be as fault tolerant and secure as possible, but I must admit, I’m extremely lax with my personal workstation. Usually, it doesn't have anything of value on it and it's protected by a router / firewall. So, I don't really do back-ups on the machine, leaving that to my home file server (or network admin). When it comes to source control though (especially when a company’s life is depending on it) I like to be extremely careful. I wanted to make sure all changes were documented on a fault tolerant server with nightly backups. Other startups feel the same, and the cost is well worth the trouble.

Unfortunately, our choice of source control providers has been letting me down. Unlike Perforce, Subversion doesn’t keep track of where branches came from, or which changes were merged from which branches. Thankfully, there’s a tool / script out there to help with it, but I’ve been having far too many problems with it. SVNMerge has missed adding and deleting files from the trunk, it’s merged in changes multiple times and shows files as conflicted when only the branch (not the trunk) has changed. Now, I know this works, because the svnmerge mailing lists are full of people that are doing this “bidirectional merging” thing, but as of right now I’m almost ready to throw out user branches entirely, at least until we get source control that is designed to do it.

Thankfully, the user branch concept isn’t really necessary with two developers (especially when those two developers are almost always working on two separate sections of the code base) but it is nice to know that I can check in any time I hit a “stopping” point, regardless of the state of the code and not actually damage anyone who might need it (e.g. if Darius has to go do a demo randomly one day). Hopefully I’ll be able to figure out what exactly is causing the problems and actually be able to keep the beloved user branch for just a little longer.