Source control has many names like revision tracking, asset management, software configuration management (SCM), change management, and source code management. They all basically mean the same thing.

Software is built from a set of components, including source files, documentation, artwork and any number of other pieces. Source control provides the system with which to manage and track these assets.

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. Controlling your development process is a critical part of producing high quality software on time and on budget. Even so, universities rarely discuss it, even in advanced software engineering courses. 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.

My name is Nick Ni, the Director of Technology for my company ionForge, and the chief architect of Evolution, which is a source control tool. In my years of experience in development lifecycle management, I have noticed an alarming deficiency in even very experienced software developers. Many development teams do not truly understand what source control is for and how to implement it effectively. I plan to change this. This will be the first in a series of articles. I will begin with basic concepts and ideas, and eventually graduate to discussing how to implement sophisticated build and deployment systems.

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, which is 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

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.

If the repository is where you keep everything you need to build your software, then your source control solution 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 checked into the repository, a record of the change is kept. Therefore, 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.

Source control tools provide a database of historical information about files. Comments can also be attached to each change.

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, 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 automatically handles 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. While the exclusive checkout restricts access before work is begun on a file, the concurrent checkout restricts access after the work is complete. In this case, the system will allow more than one person to check a file out at the same time. 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.

So there can be no accidental loss of work, because the system is controlling change submissions to the repository.

Evolution also 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 and 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.

Next time we will discuss how the source control work in a practice, and how to maintain the integrity of your source tree.

About the Author

Nick Ni is the Director of Technology of ionForge Company and the chief architect of the Evolution Source Control System. He has been a part of software teams of all sizes, developing products for consumers (such as PowerDesk, ZipMagic, and SystemSuite) to enterprise applications for financial institutions. He has led the development of Evolution from inception in 2001 to delivery in 2003 to the present time. He has been researching and implementing solutions for development lifecycle management for the last 5 years.

You can visit:
ionforge.com for more information about the Evolution Source Control System.
forums.ionforge.com to read more and ask questions.
blog.ionforge.com to get information directly from the Evolution Development Team.

(c)2005 ionForge Company. All rights reserved.