|Read more about this book|
(For more resources on TortoiseSVN, see here.)
So let’s get on with it…
Our case study
Shiny Moose Software is a software house with a small team of developers. They have just started working on their first project—a Hiragana Learning Game written in Python. The lead developer, Quinn, has created a skeleton for the project. He has written the code for the games “splash screen”.
One of the other developers, Mowbray, downloaded a compressed archive containing Quinn’s code and found that on his older computer, the CPU usage spiked massively when the code was run. He looked at the code and noticed that Quinn had made a poor choice when deciding how to detect mouse events. The problem is simple to fix, but Mowbray knows that communicating the changes to Quinn could be problematic.
Mowbray could make the required changes and then e-mail the updated code to Quinn, but what if Quinn returns to his computer and resumes his work on the application before he checks his e-mail? What if one of the other developers at Shiny Moose Software has also decided to make some changes to the code? Keeping track of changes submitted by several different developers would be confusing enough even with this relatively small application. Imagine how difficult it would become when the code is measured in hundreds, or thousands of lines, rather than just a few dozen!
This is where Subversion saves the day. Instead of copying the code from a normal shared folder, or downloading it from the company’s intranet site, Mowbray can use TortoiseSVN to check out a working copy of the code, inform the Subversion server that is currently working on that file, make the changes, and check it back in.
A word about our examples
The code snippets used in this article are incredibly simplistic. Please don’t use them as examples for how to write a Python application! Also, don’t worry too much about the language or IDE used in these examples. TortoiseSVN can be used with any language and any development environment. Even team members working on other areas, such as documentation or translation work, can take advantage of TortoiseSVN. The most important thing is to understand the version control principles which are being applied.
Working copies explained
The first thing Mowbray needs to do is check out a working copy. He can make changes to this copy and then submit the changes once he is done.
Time for action – checking out a working copy
Checking out a working copy takes just a few simple steps.
- Create a folder which you will use to store your working copies. For example, C:ProjectsMooseHiragana.
- Right-click inside that folder and select SVN Checkout… from the menu that appears.
- Browse to your project’s repository (or enter the correct network path) and click OK.
- A window containing a list of the files which have been checked out will appear.
- If the checkout was successful, you should see a list of files in your chosen directory, with a green tick on the icon of each file.
(Move the mouse over the image to enlarge.)
What just happened?
You have just checked out a working copy of the files which are stored on the repository. This is useful because it allows you to safely test, change, and experiment with the code without the risk of breaking the original code.
Once you are happy with the changes you have made, you can check them in to the repository, so that your fellow developers can synchronize their copies to see your changes.
Local repositories vs. remote repositories
We will use remote repositories in most of our examples. It is likely that you will, at some point, need to work with a remote repository—either one which is accessed via the internet, or one which is part of your company’s network. In that case, all you need to do is enter the full network/ internet address of the repository in the place of the file:/// reference in the URL of Repository box.
The MooseHiragana project is quite small, so there is no issue with checking out the entire repository. If you were working on a much larger project, which had thousands of files, then you may prefer to save time, bandwidth and storage space by checking out only the folders that relate to the part of the project you are working on.
Time for action – using checkout depth
- Using a different folder for this working copy, right-click inside the folder, and select SVN Checkout….
- This time, in the Checkout window that appears, as well as selecting the correct repository, choose Only file children from the Checkout Depth dropdown.
- You should see that when the checkout process completes, all the files that are part of the root folder appear in your working copy, but none of the folders have been checked out.
What just happened?
You have just checked out only the files that are in the root folder of the project on the Subversion server. That may not seem like a particularly useful feature when the project consists of just a few files, but imagine if there were thousands of files.
The checkout depth feature becomes useful when projects increase greatly in size. It is also useful if your team has members that work only on specific parts of the application. For example, an artist could check out only the images folder, or a translator could check out only the folder containing the localization files for the language he is working in. If the artist then needs to expand his checkout to include deeper folders, he can use the repository browser to select the extra folders that he needs.
There are a number of different checkout depth options. The following table explains what each option means.
|Checkout Depth Option||Purpose|
|Fully recursive||Checks out the entire tree, including all child folders and sub-folders.|
|Immediate children, including folders||Checks out the specified directory, including all files and child folders, but does not populate the child folders.|
|Only file children||Checks out the specified directory, including all files, but does not check out any child folders.|
|Only this item||Checks out the selected directory only. Does not populate it with files or child folders.|
|Working copy||This option is not shown on the checkout dialog, but it is the default for all other dialogs which have a depth setting. This option tells TortoiseSVN to adhere to the depth specified in the working copy.|
|Exclude||This option is not shown on the checkout dialog. It is used to reduce the depth of the working copy after a folder has already been populated.|
Have a go hero – working with checkout depth
Imagine that you are an artist. You have been hired by Shiny Moose Software and asked to redesign the logo used on the splash screen and also to create a smaller one for use in the theme of the game.
The directory structure chosen by the developers looks like this:
The images that you will be working on are stored in the /images folder. You will not need to work on anything inside the /images/artwork or /images/japanese folders.
You need to set up your working copy. Rather than cluttering your filesystem with files that you will never need to use, you have decided to checkout only the folder you need for your work—the /images folder.
Using another user account (or another PC on your network), try checking out just the contents of that folder from the repository. If you prefer, you could simply create a new working directory using the same user. However, if you do this, you should note that any changes made in that folder will be marked with your own user name. That may be fine for testing TortoiseSVN’s features, but is not good practice in a production environment.