Source Control

September 30, 2008 @ 00:20

As a kind of short follow on from yesterday’s babble on my new project, I thought I’d write a little on source control.

It’s great.
It sucks.

Both at the same time.

Ok, let me begin with what I used to do. Initially I used to just zip up any project I was working on, or save a couple of copies of it, depending what it was. This worked to an extent, but then my numberings got messy, things got lost etc.

Last year I decided to write a couple of small bash scripts that I added into my PS2 projects. One incremented the value of a number, stored in a plain text file (.counter) and used that as a build number, the version number was hard coded into my Makefile, but easy enough to change. Whenever I ran make, it called the first script, with these 2 numbers, which tar’d the project up with an appropriate version/build number. the second script then uploaded it to this server via ftp.
It was primitive. It was crude. It was slow. It worked.
I made a huge bork on my code, so I just went a couple of versions back, downloaded the tarball and started again.

Then in the second half of the year, we were given access to the university CVS server. At that time I had very little experience with *proper* version control but I knew enough to know it was antiquated. However it was what the PS2s had on them as standard so it would have to do.

vcontrol.jpgBasically, the principle we were told, was to commit any changes to the repository frequently. That way we could not accidentally delete all our several months worth of hard work (hah!) We were also told we could roll back to previous versions and other fancy things, but never told how to do it. I had a look. Then wondered how else I could try to fry my brain.
The problem I have found with a version control as a rule is that it’s awkward as hell to do anything you haven’t first been shown precisely how to do.

Through using Linux for several years beforehand, I had come across several sets of instructions using CVS (or svn) and giving exact instructions on what to type, so checking out projects is easy for me. commiting makes sense. You just say “I’m done” and it sorts out differences. Adding and deleting files can be… interesting (you have to first delete the file and then tell CVS that you’ve deleted it… but I can’t use tab to auto complete my filename then…)

Branching I have yet to actually work out how it works. The principle is that you create a branch of a project to work on a particular feature. This way you can not pollute the main project by possibly unstable code… that sort of thing… now the practice… no idea. I’m sure it works. I tried to find out how to do it on the svn server on our router. No luck yet. Hopefully someone will show me. You can guarantee as soon as they do I’ll slap myself. Returning to previous versions is a similar deal.

Apart from CVS, I’ve had a look at svn and that’s about it. Svn is (I know) far superior to CVS, although I couldn’t tell you many reasons. I could tell you many things I *think* it does better, but I will have to have confirmation before I flood the internet with yet more lies ;)

I have also just started using git. Mainly for the name to be honest. Git is a different model to CVS and svn and is supposedly (again) much better. It uses a peer to peer basis so that you don’t need to have a central server to have all the files accessible. The way these version control systems work is such that if you wanted a central server you could easily set one up, in which case it’s basically cvs with differently named commands from what I can tell. However, as git is made to scale with project size, if you had a huge group of people, all working on it at (roughly) the same time, you could quickly pull the latest version of everyone’s code off them to check that your code worked with it. I believe it is for this reason that the Linux kernel uses git for development.

Finally, left until last because I don’t know a lot about it. Microsoft Visual SourceSafe. We have a “Prototype Game Development” module this year in which we have to make a game, using Ogre3D or any other game engine we think we can learn in the time given. We are being told we should use a Visual SourceSafe repository. I have talked to a couple of people about it that have used it for their group projects, and some from industry (while I was working at Dare to be Digital) All have said it’s a pain to use, and has a tendancy to lose data. I have had a look myself and found a guide on getting it working under Linux, which told me that it was a database, mounted on a samba share… which is clearly the best and easiest way to do things :S On top of this it would seem to have very poor branching support (supposing I ever get around to learning how branching works then this is very important) I will not complain all too much until I’ve actually used the thing

So, does anyone have any suggestions about version control? What do you use? Could someone please suggest some idiot proof guide on branching?

Image: When graphs go bad! by wasabicube