Introduction

This article is a brief introduction to basic principles in managing software development projects. Source control has many aliases. Revision tracking, asset management, software configuration management (SCM), change management and source code management are the most ubiquitous of the various terms. They all basically mean the same thing.

Generally, software is built from a set of components, including source files, documentation, artwork (e.g. textures and models) and any number of other pieces. Source control provides the system with which to manage and track these assets. In essence, source control provides the following benefits:

• Provides a way to store source-controlled files in a location (e.g. server) where it can accessed by a developer anywhere, anytime.
• Maintains a detailed history of all changes in a file: what got changed, when the change occurred, which user performed the action, etc.
• Simplifies team collaboration by allowing multiple developers to work concurrently on files.
• Automatically handle merging of files and detecting conflicts.

But source control is so much more than the software itself. It requires a commitment on the part of the team to actually use the software in a disciplined manner. The problem is that nobody talks about source control. It's simply not a sexy topic, and almost always, not a part of any formal training program. Universities rarely discuss it even in software engineering classes. There are very few seminars to attend. Source control usage is primarily on the job training. Most entry-level developers' first exposure to source control is their first day on the job.

First things first, my name is Nick Ni and I am the Director of Technology for my company ionForge, and the chief architect of Evolution, which is a source control tool, available for download freely. I will be referring to it and using a lot of its terminology. I will always point out the reason behind any differences, and also tell you the analogous and generic term if there is one.

Everyone uses source control to some extent, even if it is a human procedure. For example, have you ever:

• Copied and renamed a file to common.h.bak?
• Or maybe common.h.old?
• Or perhaps even the more advanced common.h.2005-03-18?

Have you ever copied your entire code folder and date stamped it, just in case, at some point in the future, you need to see what your code looks like now? If so, then even if you don't know what source control is, you've practiced the most basic concept of source control: revision tracking. Beyond revision tracking, there is collaboration. Both of these topics will be discussed in this article, but first we need to understand the idea of the repository.

The Repository

Figure 1: Example repository

Different source control tools call the repository different things. But in general, at the heart of any source control system is a central "library" of your development assets. Evolution uses the generic term "repository". Keep in mind that this is just a way to easily explain source control on a basic level; we'll see later that the library metaphor is ultimately broken. But it suffices for now.

Rather than having many different copies of your spread out on individual users' computers, the idea is to keep everything that is required to build a project in a single location. If the repository is where you keep everything you need to build your software, then your source control serves as the librarian.

Revision Tracking

Files are "checked out" of the repository, and the "librarian" controls access to the contents of the repository.

Every time a change is committed to the repository, a record of the change is kept. This way, no previous incarnation of the file can ever be truly lost. If, for any reason at all, you need to go back in time and see what a file looked like (perhaps to narrow down who, why, and when a bug was introduced), your source control provider makes that possible. In addition, with a built-in comparison tool, a revision of a file can be compared to other revisions to provide details as to what got changed, added, or removed.

Figure 2: Example of historical records for revision tracking in Evolution

Source control tools provide automatic management of a central storage depot for development assets, and a database of historical information about files. Comments can also be attached to each change. Figure 2 provides an illustration of this concept.

Collaboration

Let's take the hypothetical case where there is no source control system and instead, development asset management is nothing more than a simple backup of a file server where all of your source is kept.

When a developer wants to work on a file, he will open the file, and save it back directly to the file server. But what happens if someone else decides to work on the file at the same time? The one who saves last wins, and the first person's work is lost. There are ways to manually control this process, except perhaps by email notifications, but this obviously becomes an unreasonable burden, and more importantly, prone to error.

With a source control tool, this process of notification becomes automatic, and also can automatically handle access restriction for you. There are several ways this is handled, the first being the exclusive checkout.

When one person checks a file out, the system can forbid any other person from checking it out. This prevents confusion because only one person may be altering a file at any given time.

While often a perfectly acceptable solution, it can become a bottleneck in larger teams. You don't want anyone to wait for very long for a file to begin his or her work. The next step up from exclusive checkouts is the shared (or concurrent) checkout. In this case, the system will allow more than one person to check a file out and restricts access on check in. The loss of work described above in the case of the file server is prevented by the source control system. When multiple people have a file checked out, after the first check-in, every subsequent check-in will be required to reconcile the differences. Therefore, there can be no accidental loss of work, because the system is controlling access to the repository.

Figure 3: Example of shared lock in Evolution

Evolution provides an "in-between" type of checkout, for those who prefer the absoluteness of the exclusive checkout, but who want to minimize the wait. We call it a deferred lock, but it just means that you can get in line for a file. The person who currently has the file is sent a nice email telling them to hurry up, and when they are done, the next person in line automatically gets the file and receives an email telling them so.

Conclusion

This article is a very basic overview of the core concepts of source control. There are many systems available to you, and they all will have slight variations of the ideas described above, but the goal is always the same:

To automatically manage historical revisions of development assets and to facilitate collaboration.

I encourage you to try out our source control technology at ionForge. You can download a free personal edition of Evolution.

In the next article, I will delve a little deeper into source control and provide some usage examples of how source control can assist you in real world situations.