Introduction

[gitmagic.git] / intro.txt

= Introduction =

I'll use an analogy to introduce version control, which can also be called revision control, source control, or source code management. See the Wikipedia article for a normal explanation.

== Work is Play ==

I've played computer games almost all my life. In contrast only started using version control systems as an adult. Not surprisingly, I'm a lot more familiar with video game concepts than version control ones. I'm certain I'm not alone.

Think of editing your document, or your code, or whatever, as playing a game. Once you've made a lot of progress, you'd like to save. To do so, you click on the "Save" button in your trusty editor.

But this will overwrite the old version. It's like those old school games which only had one save slot: sure you could save, but you could never go back to an older state. Which was a shame, because your previous save might have been right at a really fun part of the game that you'd like to revisit one day. 

== Version Control ==

You can "Save As..." a different file, or copy the old one somewhere first before saving if you want to savour old versions. Maybe compress them too to save space. We have just described a primitive labour-intensive form of version control.

Let's make the problem slightly tougher now. Say you have a bunch of files that go together, such as collection of source code for the same project, or files for a website. Now if you want to keep an old version you have to copy a whole directory of stuff. Keeping many versions around is inconvenient to do by hand.

In some computer games, saving the game actually writes a directory full of files. They hide these details from the player and present a convenient interface for you to manage saves.

This turns out to be a basic capability of all version control systems. They all have nice interfaces to manage a directory of stuff. You can save its state every so often, and be able to load any one of the saved states later on. They're also smart about using space, by exploiting the fact that only a few of the files usually change between version to version.

== Sharing Saved Games ==

Now imagine a very difficult computer game. So difficult to finish that many experienced gamers all over the world decide to team up and share their saved games to try to beat it. Real-life examples of this include doing speedruns of certain games. Players specializing in different levels of the same game collaborate to produce amazing results.

How would you set up a system so they can get at each other's saves easily? And upload new ones?

In the old days, every project used centralized version control. A server somewhere held all the saved games. Nobody else did. Every player kept at most a few saved games on their machine. When a player wanted to make progress, they'd download the latest save from the main server, play a while, save and upload back to the server for everyone else to use.

What if a player wanted to get an older saved game for any reason? Maybe the current saved game is in an unfinishable state because somebody forgot to pick up an object back in level three, and they want to find the latest saved game where the game still can completed. Or maybe they want to compare two older saved games to see how much work a particular player did.

There could be many reasons to want to see an older revision, but the outcome is the same. They have to ask the central server for that old save. The more saves they want, the more communication that is required.

The new generation of version control systems are known as distributed systems, and can be thought of as a generalization of the centralized systems. When players download from the main server they get every saved game, not just the latest one. It's as if they're mirroring the central server.

One immediately obvious benefit is that when an old save is desired for any reason, communication with the central server is unnecessary.

== Merge Conflicts ==

An interesting problem arises in any type of revision control system. Suppose Alice and Bob have both independently downloaded the latest saved game. They both play the game a bit more and save. What if they both want to submit their new saves? Let's say Alice uploads first. Nothing spectacular happens, but when Bob tries to upload his save, the system realizes that his state does not chronologically follow Alice's state.

Ideally, the team possesses some sort of tool that can merge together progress from two different saved games into a new saved game. With such a tool, the problem is solved because Bob can merge Alice's state into his, and then upload the result. But in general, there is no such tool that can handle all cases and sometimes the only solution is human intervention.

Many revision control systems can automatically sort out simple merge conflicts with text files, and will ask a human to help if they cannot resolve the problem themselves.