ID:104906
 
How many times have you made a change to a project you are working on, only to realise it isn't what you wanted, and you have no backup? It's pretty frustrating, isn't it. So you come up with all these fancy backup strategies to try and avoid that, but still from time to time it happens. You just don't backup at the right time, or you lose a backup.

Personally I had a beautiful example back when I was in university. As a part of my thesis, I was to develop a peer to peer networked program in Java, from the ground up. This meant designing the protocol, deciding on the concept of who shares what with who, identification, performance testing, the works. Without meaning to blow my own trumpet, my implementation was pretty respectable for a university student. I demo'd the system to my supervisor, wrote up my thesis, submitted it.

"Looks okay so far. Can you provide the source code on CD with this?" Yeah sure no problem I'll just ... where is it? It was just meant to be here, on my nice and stable server ... that I'd reformatted ... *sheds a manly tear*

Without my source code, my submission would be invalid, and my thesis ruined. Not least, imagine if I spotted a bug before the final demo, what then? Thankfully for me, Java is reasonably simple to de-compile. After 4 days of code clean-up from the disassembly, my lesson had truly been learned, I must use a better system. But surely this is a common problem, surely there is a better solution already out there?

There is: revision control. Revision control is really simple in concept. You have a file on a server, you make changes locally. You compare the two files, and the server stores the differences, and says "I have version 2 of this file now". Rinse, and repeat. What if you mess up? Ask the server for the previous version, no harm no foul eh?

There's another concept at work here, which applies for teamwork: locking. Say you have two team-members, and a server. Team member A wants to edit the file, so they lock it on the server. Team member B can happily view the file and use it locally, edit it locally, but they can't send any changes to the server for it. A is now free to edit without worrying about destroying a version he never received, and commits to the server.

What about B? B pulls the updated version, and a "conflict" arises. If he's lucky, the software will just merge the changes in, he gets the update AND keeps his changes. Otherwise, he compares the server version side-by-side against his own, and corrects the local version until it's suitable, and says "okay, conflict resolved". He's now free to send his version to the server. No need to coordinate in advance, just lock and go, then everyone knows what you're changing. They don't even have to avoid that file, they can resolve a conflict before they finish up.

"This is magic, Stephen! Where do I start?" Well, first you need to pick a tool. This is a pretty big topic, so I'll give you a hand: Subversion

To interact with a server, you may want TortoiseSVN http://tortoisesvn.net/downloads

For the server, you could run your own. Instead though, I recommend you give a free service a go, such as ... Google Code perhaps? http://code.google.com/hosting/createProject

Both websites have a little documentation on tool use. I will follow this up with an article on subversion specifically, using these tools and services, for a more in depth tutorial on the matter.

Thank you for reading.