Source Control

A vast majority of professional game companies use software known as “Source Control” – applications which store current and past versions of files related to their projects, along with comments about what may have changed with each change from version to version.

These applications include SourceSafe, PerForce, SVN, and CVS, to name a few of the more popular varieties. Each of these includes the same major features – the ability to store multiple versions of files in a project – but minor details may vary. For example, SourceSafe stores “deltas” of files (that is, only what changed from version to version), making for potentially smaller overall storage space for projects with lots of changes. PerForce, on the other hand, has “atomic changes”, where you can post groups of files to the program, and they will all be linked in your comments.

Why is this important to you? For a variety of reasons:

Most companies use some form of source control – knowing about source control and how to use it will make you more valuable to companies that you might want to apply to someday.

It helps you with your own backups – backups are one key to most developer’s lives. If you are developing just about any application, having a history of that applicaiton, which allows you to find when/where you introduced bugs, may be critical to your development of that application.

It helps you track your progress – using the comments feature, and just seeing what you’ve submitted to source control, will help you keep track of your personal progress, and see just how far you’ve come.

Some terminology that Source Control programs use:Get / Sync – a request to the source control program for a desired version of all files it monitors. This often is the latest version (Get Latest / Sync to Head), but many of these programs also allow you to get files from a specific date/time, from a given version, or from a label (details below).

Check out / Edit – a notification to the source control program (and other users) that you are modifying a file or group of files. This ensures that the program knows what version of the file you are starting from, which can be helpful later.

Check in / Submit – a notification that you are posting a new version of a file (or group of files) to source control. This usually includes the option for adding a comment about what you changed, and will often mark the file as read-only on your machine, to ensure that you don’t accidentally make changes without checking the file out again.

Undo Check Out / Revert – If you check out a file, but decide later that you didn’t need those changes, or made mistakes, you can undo the check out, notifying the source control application that you no longer need that file, and telling it to copy down its copy of that file back to your computer.

History / Revision History – a list of all the versions of a given file that have been placed in source control, along with comments about each version. Some programs list out what other files were checked in at the same time, or list a revision number for easy reference back to the change. Most will let you do a Get/Sync from an entry in the History list, so you can undo changes in case of bugs.

Label – a marking in the source control database which includes information about the current version of a selection of files contained in the source control application. This can be useful for marking when a particular demo build is made, or when specific features are added.

Merge – When multiple developers are working on a single project, the source control application may be set so that a single file can be Checked Out by multiple people. In this case, the source control application will request that each user “merge” the changes of others who have checked in the file since the current developer has checked it out. For example, you check out a file on version 5, as does your friend Sarah. Sarah then checks in the file (version 6), after which you try to check yours in (version 7). The source control application will notify you that a Merge must occur, and will likely attempt to do it for you, but if you and Sarah have modified the same line, the application will ask you to review the changes and make modifications yourself.