If you have a good working knowledge of SCM solutions then you can skip this article and go on to SCM: Part 4 - Setting Up SCM For Use With GameMaker: Studio.
As a developer you should have heard about Source Control Management or SCM, 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 may seem unnecessary and you may be unsure exactly what it entails. However it most definitely is necessary no matter what the scope of your development process is as it is a powerful tool for maintaining your projects tidy and making sure any changes can be un-done later if they don't work.
To get an idea of what it does 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 (
Document_old.txt), and, if you're clever, you add a version number or date (
DocumentMarch2007.txt) 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 Management?
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 then 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 source control management. Moreover, SCM solutions provide some additional useful functions such as: comparison of versions (visual), rollback, notifications, tags, branches, history, locks and so on. Due to these functions the use of SCM is helpful for a single developer in his work, since it makes backup of different versions of a source code unnecessary.
What is SVN?
GameMaker: Studio comes bundled with SVN support already, since it is the easiest of the SCM solutions out there to set up and start using, and it also supports local repositories (the more complex SVN solutions require a server URL for the repository). If you have never used an SCM solution before, SVN is a great solution to start with and offers most of the same basic tools as more complex solutions like GIT. But 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 that you use the 1.8 version of SVN that comes bundled with GameMaker: Studio, or failing that Sliksvn as the main svn client based off of the Apache Subversion code base. If you are not comfortable with operating it through the command line prompt (most SCM solutions use command line, but they also have third party GUIs), 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 solution in itself and will only work if there is another low-level SVN package like Sliksvn already installed).
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 SCM solutions offer, and then we can see how all this applies to GameMaker:Studio :
- Repository : The database storing the files.
- Server : The computer storing the repository.
- Client : The computer connecting to the repository.
- Working Copy : Your local directory of files, where you make changes.
- Trunk/Main : The primary location for code in the repository. Think of code as a family tree — the trunk is the main line.
- Add : Put a file into the repository for the first time, i.e. begin tracking it with Version Control.
- Revision : What version a file is on (v1, v2, v3, etc.).
- Head : The latest revision in the repository.
- Check out : Download a file from the repository.
- 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.
- Checkin Message : A short message describing what was changed.
- Changelog/History : A list of changes made to a file since it was created.
- Update/Sync : Synchronize your files with the latest from the repository. This lets you grab the latest revisions of all files.
- Revert : Throw away your local changes and reload the latest version from the repository.
- Branch : Create a separate copy of a file/folder for private use (bug fixing, testing, etc).
- Change : Finding the differences between two files. Useful for seeing what changed between revisions.
- 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.
- Conflict : When pending changes to a file contradict each other (both changes cannot be applied).
- Resolve : Fixing the changes that contradict each other and checking in the correct version.
- 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.
- 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 (
list.txt) 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
list.txt, which contains “milk”, and he can browse the changelog to see that Andrew put “milk” the day before. He now knows that it has been changed, and what changes were made, and can then make his own changes to the file without worrying about Andrew working on it at the same time, and so on..
GameMaker:Studio and SCM
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 article expands on what you have learned here and applies it directly to GameMaker: Studio, providing all you should need to get you started working in a source controlled environment: