Program Arcade Games
With Python And Pygame

Language
English
Russian - Русский
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:

Get any prior version of their program
Easily share code between developers
Easily work independently of other developers
Know exactly what changed in the code, when, and by who
Recover an accidentally deleted or overwritten file
Go back and create a bug-fix on prior versions of a program
Work on multiple computers and keep files in sync

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. Centralized version control, using software like Subversion. The other type are Distributed Version Control Systems (DVCS), using software like Git and Mercurial. There are also other products like ClearCase, but those are abominations and should be avoided.

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

In this class we use Mercurial repositories. 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 this version control system. Even your worksheets will be turned in this way.

4.2 Software Needed

Video: Installing TortoiseHg

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 Cloning Repositories

Video: Cloning a Repository

We'll start this class with a code repository that has already been created. Once you sign up for a class via this website, a repository is automatically created for you. Now we just have to find it. Click on the link below:

http://programarcadegames.com/code_repository

You should be presented with a login dialog that looks like this:

fig.login — Figure 40.9: Code Repository Login Dialog

Enter your e-mail, and the password you created for this website. Don't use your Simpson password that you use for e-mail. You should end up at a website that looks like this:

fig.mercurial — Figure 40.10: Code Repository Website

Or possibly this:

fig.rhode — Figure 40.11: Code Repository Website

(Currently I'm still working on this part of the website.)

From here, you should see a repository that has the same name as your e-mail address. Click on this repository, and then copy the address from the address bar like this example:

fig.copy_address — Figure 40.12: Copy Repository Address

Your browser may look a bit different, if you aren't using Chrome.

Now, we need to tell TortoiseHg to clone the repository at this address. Open up a folder where you wish to place your repository. You can also place your code repository on the desktop. 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 40.13: 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 40.14: Paste Address

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

fig.clone — Figure 40.15: Clone Repository

Before it can start, it will ask you to enter your repository username and password:

fig.tortoise_login — Figure 40.16: Login Window for Tortoise

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 40.17: Code Repository Folder

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

4.4 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 40.18: Icons of Changed Files

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

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

This will pop up the commit dialog box:

fig.commit_dialog — Figure 40.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 40.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.5 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 40.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 40.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 40.25: Workbench Window

4.6 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:

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

4.7 Pulling Changes

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

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 40.27: Code Repository After Pull

4.8 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 40.28: Update Code

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

fig.confirm_update — Figure 40.29: Confirm Update Code

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

4.9 Merge Changes

Video: Pulling and Merging

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

Update:

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

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

Merge:

Sally pulls the code from the server at 1 pm.
Bob pulls code from the server at 2 pm.
Bob changes the code.
Sally changes the code as well.
Bob pushes the changes at 3 pm.
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 40.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:

Confirmation after the merge:

Commit the changes that occured as part of the merge:

fig.commit_merge — Figure 40.33: Merge Dialog

Finish screen:

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

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

Program Arcade GamesWith Python And Pygame

Program Arcade Games
With Python And Pygame