Web Development
Using PHP

Follow on
Twitter

Version Control

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

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.

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
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
Code Repository Website

Or possibly this:

fig.rhode
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
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
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
Paste Address

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

fig.clone
Clone Repository

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

fig.tortoise_login
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
Code Repository Folder

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

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

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

fig.folder_icon_change
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
Commit Menu

This will pop up the commit dialog box:

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

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
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
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
Workbench Window

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

Pulling Changes

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

fig.pull_changes_button
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
Code Repository After Pull

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
Update Code

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

fig.confirm_update
Confirm Update Code

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

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
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
Merge Dialog

Confirmation after the merge:

fig.merge2
Merge Dialog

Commit the changes that occured as part of the merge:

fig.commit_merge
Merge Dialog

Finish screen:

fig.merge4
Merge Dialog

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

fig.merge5
Merge Dialog

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