An Introduction to Source Control

=Introduction= As a developer you should have heard about Source Control and SVN, but if you work alone and you do not have to share sources with other developers, or are a small team just starting out, then the use of source control is usually unnecessary and you may be unsure exactly what it entails. Let's start by looking at your own hard-drives! Got any files like this? It’s why we use the “Save As” option in our text editors and graphics programs, as you want to have the new file without obliterating the old one, "just in case". It’s a common practice, and usually works like this:


 * You make a single backup copy, and, if you’re clever, you add a version number or date ( or  ) and you may even use a shared folder so other people can see and edit files without having to send them over email (hoping they re-label the file after they save it, so that you don't go and lose their changes by saving over it yourself!).

That shared folder/naming system is fine for class projects or one-time papers, but software projects? Not a chance! Do you think the Windows source code sits in a shared folder like “Windows2007-Latest-UPDATED!!”, for anyone to edit and that every programmer just works in a different sub-folder? Not at all - large, fast-changing projects with various authors need some form of source control (think : “file database”) to track changes and avoid general chaos.

=What is Source Control?= As we mentioned in the introduction, you may say - "It is simple: put all the resources into a network drive, and several developers will be able to work with them", and that is a possible decision. But what happens if two developers modify the same file? Changes to one of them will be lost! This is where source control comes into the picture as it greatly helps to avoid this problem.

The basic idea is to store recently added sources on a server and rather than modify them directly, each developer gets his own local copy instead which he can then change and work with. If a developer wants to modify a file, he performs checkout (this means that he informs others that he is going to modify that file), then, when the modification is done, he uploads (or commits) the file to the server. The server will ten resolve any possible conflicts (when two users modify the same file) automatically on the line level, i.e. if one developer modifies the top lines and another - the bottom ones, the file will be automatically merged. If they modify the same lines then the developer being the last to upload the changes has to resolve the conflict manually, but this should seldom occur unless your team are very disorganized!

This is the main function of a source control system. Moreover, source control systems provide some additional useful functions such as: comparison of versions (visual), rollback, notifications, tags, branches, history, locks and so on. Due to these functions using of source control is helpful for a single developer in his work, since it makes backup of different versions of a source code unnecessary.

=What is SVN?= SVN is the name given to the method of working with sub-versions using the free license Apache Subversion, which is installed in the form of an independent software package to control all the aspects of maintaining, changing and comparing versions of your game as you work on it. We recommend Sliksvn as the main svn client based off of the Apache Subversion code base and if you are not comfortable with operating it through the command line prompt, we also recommend that you get yourself a copy of TortoiseSVN which is a windows client that provides graphical control over svn (note that tortoise is not an svn client in itself and will only work if there is another low-level client package like Sliksvn already installed).

=Core Concepts= Okay, so you now know what source control is, but just what can it do other than keep versions of my files? Well, quite a lot more actually! let's just run through the basic concepts of what most svn clients offer, and then we can see how all this applies to GameMaker:Studio :

Basic Setup

 * 1) Repository : The database storing the files.
 * 2) Server : The computer storing the repository.
 * 3) Client : The computer connecting to the repository.
 * 4) Working Copy : Your local directory of files, where you make changes.
 * 5) Trunk/Main : The primary location for code in the repository. Think of code as a family tree — the trunk is the main line.

Basic Actions

 * 1) Add : Put a file into the repository for the first time, i.e. begin tracking it with Version Control.
 * 2) Revision : What version a file is on (v1, v2, v3, etc.).
 * 3) Head : The latest revision in the repository.
 * 4) Check out : Download a file from the repository.
 * 5) Check in/Commit : Upload a file to the repository (if it has changed). The file gets a new revision number, and people can “check out” the latest one.
 * 6) Checkin Message : A short message describing what was changed.
 * 7) Changelog/History : A list of changes made to a file since it was created.
 * 8) Update/Sync : Synchronize your files with the latest from the repository. This lets you grab the latest revisions of all files.
 * 9) Revert : Throw away your local changes and reload the latest version from the repository.

Advanced Actions

 * 1) Branch : Create a separate copy of a file/folder for private use (bug fixing, testing, etc).
 * 2) Change : Finding the differences between two files. Useful for seeing what changed between revisions.
 * 3) Merge : Apply the changes from one file to another, to bring it up-to-date. For example, you can merge features from one branch into another.
 * 4) Conflict : When pending changes to a file contradict each other (both changes cannot be applied).
 * 5) Resolve : Fixing the changes that contradict each other and checking in the correct version.
 * 6) Locking : Taking control of a file so nobody else can edit it until you unlock it. Some version control systems use this to avoid conflicts.
 * 7) Breaking the lock : Forcibly unlocking a file so you can edit it. It may be needed if someone locks a file and goes on holiday.

So, a typical usage scenario goes like this:


 * Andrew adds a file to the repository. He checks it out, makes a change (puts “milk” on the list), and checks it back in with a checkin message (“Added required item.”). The next morning, Mike updates his local working copy and sees the latest revision of , which contains “milk”, and he can browse the changelog to see that Andrew put “milk” the day before.

=GameMaker:Studio and SVN= GameMaker:Studio now integrates source control into the user interface and communicates all changes and edits to your svn client. However, for this to happen you should set up GameMaker:Studio properly and be aware of how it functions and what is (and isn't) capable of. The following pages will supply you with all the information you should need to get you started working in a source controlled environment :


 * 1)  Getting Started with Source Control : Prepare your pc with the correct source control packages
 * 2)  Setup Source Control and GameMaker:Studio : Setup GameMaker:Studio to use source control
 * 3)  Using Source Control : Using source control with GameMaker:Studio