#4 Version Control

Before we continue too far, I think it’s important to mention version control.

Much as this is part of a “tutorial” series, I won’t be explaining much about how to use a particular kind of version control for one reason only. I can’t tell you which version control solution to use. There’s not a right answer to that. Many factors come into play, in some ways, moreso than a build system. Also, it doesn’t directly affect the development of the (game) project. The most important thing is that you use something.

So, I’ll start by explaining some of the deciding factors, from my point of view.

  • Familiarity – This is probably the main factor in any case. If you’re used to a particular solution, then you’re more likely to be able to use it seamlessly and not worry about it. That’s not to discourage you from experimenting with other version control systems, but when the decision comes, a safe bet is almost always better than a potential risk.
  • Availability – This depends a lot on the scale of the project and it’s aims. You can get version control hosting for free for open source projects and it’s pretty cheap for closed source projects, but sometimes you don’t necessarily want to shell out every month for a project that you can’t make open source for whatever reason but will probably never bring in any money (or at least not soon).
  • Decentralised – This is a little bit of an empty case as all decentralised systems I’ve seen can be set up so one repository acts as a central server, if that’s what you want. But on the other hand, if you use a proprietary version control system with a centralised server, it can come with extra features built in like automatic backups or maybe things like commit guards, where it checks that the code at least compiles before it allows it.
  • Team – If you’re a one man team, or in a small group, you probably don’t need insanely comprehensive merge capabilities, but what is more important is the ease of use and integration of tools. If the project is likely to fluctuate, then a strong branching and merging ability is a must-have.

There are many other things which could be involved in the choice too. But let me give you a few examples of version control I’ve used in the past now.

  • During university, I didn’t have access to any formal version control for my projects, but I did have a small amount of free webspace over at sdf.lonestar.org. It wasn’t a lot, but it was enough to backup my stuff on. I modified my build scripts, when I compiled (I believe it was actually a separate “target”) to increment the version number in a file, then to archive the source files as {projname}-{version}.tar.gz and upload to my ftp. It was dirty, it wasn’t efficient, it worked. I still have all the iterations of my programs from that period if I ever need to go back to them.
  • Shortly afterwards, my university gave us access to a cvs server. Incase anyone doesn’t know cvs (Concurrent Versions System) was developed in the mid 80s. It is now seriously dated. It handles binary files badly. Why were we given access to that? Because the university had ~40 PS2 devkits with cvs installed by default, but no other version control system. It logically made sense to use that for the relatively small amount of work that will be done.
  • Due to familiarity with cvs, I later changed to svn (subversion) for personal projects, which is basically the next step. It has better support for binary files and is a bit more optimised for modern work. It’s also very well supported on all platforms and has TortoiseSVN for Windows which makes integration into Windows painless.
  • At work, we use Perforce, which works pretty well. It’s centralised so we have a secure central depot which we know should be stable. The issues with this solution is that, for one thing, branching and merging can be problematic and can often cause bad merges or confusion. Also, if a large change is being worked on, it can’t be submitted (and thus tracked) until it’s fully working, as the build machines are also tied to the same system.
  • For my personal projects now, I use git. Being decentralised, I can make small commits to my private repository, tracking changes as they happen, rather than waiting until the whole of a feature is implemented, when it can be submitted to a main repository. In fact, if I’m working on something big at work which will take multiple days, I often make a small git repository to track the changes I make, so I could roll back anything that didn’t work, without having to roll back the entire change. It’s actually saved a lot of time on several occasions. You can also get TortoiseGit. And branch and merge easily.

So far, I’ve had nothing negative to say about git. That is because, for me, it’s the best solution right now. I’m familiar with the interface and it has all the features I need. That’s not to say that it’s without faults. It is by far the most complex solution I have used. It takes a bit of getting used to the whole merging system. I’m not sure it would be the best solution for people who aren’t overly technically minded, and just want to get work done (designers, artists) I realise this might sound derogatory, but I don’t intend it in that way.

Now, I’m considering at this stage doing a quick how-to on setting up git for use with Maratis, but there are many many great guides on this already that I can’t hope to compete with, however, if I get cries for instructions, I will update this “tutorial” to include a short guide.

After this brief interlude, we’ll continue with our programming, making a timer system so we can make things happen at certain intervals.

<-Previous Next->


Leave a Reply

Your email address will not be published. Required fields are marked *

Diary of a Slacker