intro.txt

   1 = Introduction =
   2
   3 I'll use an analogy to introduce version control. See [[http://en.wikipedia.org/wiki/Revision_control][the Wikipedia entry on revision control]] for a saner explanation.
   4
   5 == Work is Play ==
   6
   7 I've played computer games almost all my life. In contrast, I only started using version control systems as an adult. I suspect I'm not alone, and comparing the two may make these concepts easier to explain and understand.
   8
   9 Think of editing your code or document, 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.
  10
  11 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. Or worse still, your current save is in an unwinnable state, and you have to start again.
  12
  13 == Version Control ==
  14
  15 When editing, you can "Save As..." a different file, or copy the file somewhere first before saving if you want to savour old versions. Maybe compress them too to save space. This is version control, but very primitive and labour-intensive.Computer games improved on this out long ago, many of them allowing multiple automatically timestamped save slots.
  16
  17 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 archive a whole directory of stuff. Keeping many versions around is inconvenient to do by hand, and gets expensive fast.
  18
  19 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.
  20
  21 This is also 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 you can load any one of the saved states later on. Unlike most computer games, they're usually smart about using space, by exploiting the fact that only a few of the files usually change between version to version, and not by much.
  22
  23 == Distributed Control ==
  24
  25 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.
  26
  27 How would you set up a system so they can get at each other's saves easily? And upload new ones?
  28
  29 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.
  30
  31 What if a player wanted to get an older saved game for some reason? Maybe the current saved game is in an unwinnable 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 can still be completed. Or maybe they want to compare two older saved games to see how much work a particular player did.
  32
  33 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 saved game. The more saved games they want, the more communication that is required.
  34
  35 The new generation of version control systems, of which Git is a member, are known as distributed systems, and can be thought of as a generalization of 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.
  36
  37 This initial cloning operation can be expensive, especially if there's a long history, but it pays off in the long run. One immediate benefit is that when an old save is desired for any reason, communication with the central server is unnecessary.
  38
  39 == Merge Conflicts ==
  40
  41 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.
  42
  43 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.
  44
  45 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.