Program Arcade Games
With Python And Pygame

Dutch - Nederlands
Hungarian - Magyar
Portuguese - Português
Russian - Русский
Spanish - Español
Turkish - Türkçe

Version Control

4.1 What is Version Control?

No serious development should be done without version control. In fact, version control is so important, many developers would argue that almost no development should be done without version control.

Version control allows developers to:

Version control saves untold time and headaches. It used to be that version control had enough of a learning curve that some developers refused to use it. Thankfully today's version control tools are so easy to use there's no excuse not to.

There are two main types of version control. The original version control systems were “centralized.” Subversion (SVN) is a very popular piece of software that supports this type of version control. The other type is a “Distributed Version Control Systems” (DVCS). There are two popular versions of DVCS in use today, Git and Mercurial. Either works fine, but for this tutorial we will standardize on Mercurial. Mercurial is sometimes also known as Hg. Get it? Hg is the symbol for Mercury. We programmers are a hilarious bunch.

If you are taking this as part of a Simpson College class with Dr. Craven, all the programs you write will be turned into grade using the Mercurial version control system. Even your worksheets will be turned in this way.

4.2 Software Needed

Video: Installing TortoiseHg

Changes that you and other developers make to the code are stored in “code repositories.”

Just like the web can be browsed with different web browsers, Mercurial code repositories can be browsed with different clients. We'll use a client called TortoiseHg.

Download TortoiseHg from:

You can also follow along with the video tutorial to the right.

4.3 Forking Repositories

We'll start this class with a code repository that has already been created. The code is currently hosted on a website callded “BitBucket.” Go to BitBucket and sign up:

Once you have signed up, go to the code repository that I've created:

The next step is to create your own copy of my repository so that you can change it however you like. Your copy will be called a “fork” of my original code. So click the “Fork” button:

Figure 50.9: Fork Repository Button

BitBucket will ask for details about the fork. You can set your own name for the fork or use the same name. But I highly recommend making the fork private! Otherwise anyone can copy and look at your code. If someone copies your code they aren't learning anything and that's not good. See below for the settings I recommend:

Figure 50.10: Fork Repository

4.4 Cloning Repositories

Now, we need to tell TortoiseHg to clone the repository. First, let's copy the web address for this repository.

Figure 50.11: Copy Repository Address

Next, create a new empty folder where you wish to place your repository. You can also place your code repository on the desktop.

Figure 50.12: Create a New Desktop Folder

Name the folder.

Figure 50.13: Naming the Folder

Right-click in an empty area to bring up the context menu, and select the clone option out of the TortoiseHg menu:

Figure 50.14: Hg Clone Menu

That should bring up the clone dialog box. Right click in the text box for Source and paste the address we copied earlier:

Figure 50.15: Paste Address

Confirm both the source and destination locations are correct, then press Clone.

Figure 50.16: Clone Repository

Before it can start, it may ask you to enter your repository username and password.

When you are done, you should see a folder with a green checkmark. If the green checkmark does not appear, you might need to hit F5 so the computer refreshes the desktop and you can see it.

Figure 50.17: Code Repository Folder

You can now open up this folder and edit the files like normal.

4.5 Committing Changes

Video: Committing Changes

When you have finished making a change, you can commit it to the code repository. Don't worry! The great thing about this type of commitment, is that you can go back on any “commit” that you make. Going back on a commitment is a feature with this software! How cool is that?

In the example below, I have changed one file, and added a new file, The file no longer has a green checkmark, but a red exclamation point to let you know it has changed. has no icon, showing you that it is not under version control at all.

Figure 50.18: Icons of Changed Files

Not only will these files show their icon as being different, so will the parent directories:

Figure 50.19: Parent Folders Also Change Icons

You can commit changes to individual files, or your can commit all the changes in an entire code base by selecting the parent folder and clicking “commit”:

Figure 50.20: Commit Menu

This will pop up the commit dialog box:

Figure 50.21: Add a New File

Important! This will not automatically add new files. New files are in purple. You need to put a check next to the new file to tell the computer you want it to be part of the this change set:

Figure 50.22: Add a New File

Everytime I get something new working, or I want to create a spot in time that I can go back to, I do a commit. Typically this is somewhere between five minutes to an hour of working. Rarely do I work more than an hour without commiting.

4.6 Pushing Changes to the Server

Video: Pushing Changes

At this point, all changes that you have made are on your own computer. Other people can not see them, and you can not pull them onto another computer. The instructor can not see your changes yet. If you are on a school computer, you will not be able to pull them onto your laptop computer. To do this, you will need to share your changes.

When you are ready to share your changes, you need to “push” the changes to the server. To do this, right click on your repository folder and select “Hg Workbench”.

Figure 50.23: Select Hg Workbench

This will bring up the Hg Workbench. The workbench allows you to see every change, and manage those changes. In this case, we want to press the button to push all our changes to the remote server.

Figure 50.24: Workbench Window

You will enter your username and password, and the changes will be moved to the server. Look for the confirmation message:

Figure 50.25: Workbench Window

4.7 Changes

Video: Pulling and Updating

Ok, if you've been working at a school computer and you've pushed those changes to the server, how do you get that code onto your home computer? This is a two step process:

  1. Pull the changes.
  2. Update to the new changes --or-- Merge the changes.

4.8 Pulling Changes

For step one, all you need to do is hit the “pull” button and log in:

Figure 50.26: Pull Changes Button

Now you will have the changes from the server saved in your code repository database. But your local files have not changed! You can see the new changes in your repository window. Note that those changes are in a different “branch” than the code on your local computer:

Figure 50.27: Code Repository After Pull

4.9 Update Changes

If you haven't changed the code on your local computer since the changes on were made on the server, all you need to do is update your code to the code pulled from the server. To do this, right-click and click update:

Figure 50.28: Update Code

Then a confirmation dialog will pop up. Click “Update”.

Figure 50.29: Confirm Update Code

At this point, the code on your computer will be up to date with the latest changes from server.

4.10 Merge Changes

Video: Pulling and Merging

Here are two scenarios showing the difference between “update” and “merge.”


  1. Sally pulls the code from the server at 1 pm.
  2. Bob pulls code from the server at 2 pm.
  3. Bob changes the code.
  4. Bob pushes the changes at 3 pm.
  5. Sally pulls the code at 4 pm.

This example is an update because Sally did not change the code between pulls.


  1. Sally pulls the code from the server at 1 pm.
  2. Bob pulls code from the server at 2 pm.
  3. Bob changes the code.
  4. Sally changes the code as well.
  5. Bob pushes the changes at 3 pm.
  6. Sally pulls the code at 4 pm.

This is a merge because both developers changed the code between pulls. Sally needs to merge Bob's changes into the changes she made.

In the example below, see that there are circles representing changes on both branches of the code. Instead of selecting “update,” we need to select “merge with local.”

Figure 50.30: Code Repository Pre-Merge

As long as both branches didn't change the exact same line of code, the merge should happen cleanly and without conflicts. The next dialogs show the merge process:

Figure 50.31: Merge Dialog

Confirmation after the merge:

Figure 50.32: Merge Dialog

Commit the changes that occured as part of the merge:

Figure 50.33: Merge Dialog

Finish screen:

Figure 50.34: Merge Dialog

Finally, we can see the two branches of code have been merged.

Figure 50.35: Merge Dialog

You are not logged in. Log in here and track your progress.

About Buy the Book Help Translate My College My Twitter