Program Arcade Games
With Python And Pygame

Language
English
Dutch - Nederlands
French
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: http://tortoisehg.bitbucket.org/

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:

https://bitbucket.org/

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

https://bitbucket.org/pcraven/program-arcade-games-work

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:

fig.fork
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:

fig.fork2
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.

fig.clone1
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.

fig.new_folder
Figure 50.12: Create a New Desktop Folder

Name the folder.

fig.name_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:

fig.hg_clone_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:

fig.paste_address
Figure 50.15: Paste Address

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

fig.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.

fig.repository_folder
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, main_program.py and added a new file, new_file.py. The file main_program.py no longer has a green checkmark, but a red exclamation point to let you know it has changed. new_file.py has no icon, showing you that it is not under version control at all.

fig.changed_file
Figure 50.18: Icons of Changed Files

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

fig.folder_icon_change
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”:

fig.commit
Figure 50.20: Commit Menu

This will pop up the commit dialog box:

fig.commit_dialog
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:

fig.add_file
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”.

fig.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.

fig.workbench_window
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:

fig.confirm_changes_pushed
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:

fig.pull_changes_button
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:

fig.pre_update_code
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:

fig.update_code_menu
Figure 50.28: Update Code

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

fig.confirm_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.”

Update:

  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.

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. 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.”

fig.pre_merge_code
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:

fig.merge
Figure 50.31: Merge Dialog

Confirmation after the merge:

fig.merge2
Figure 50.32: Merge Dialog

Commit the changes that occured as part of the merge:

fig.commit_merge
Figure 50.33: Merge Dialog

Finish screen:

fig.merge4
Figure 50.34: Merge Dialog

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

fig.merge5
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