What is a Source Code Control System?

One of the tools SAPIEN will release in February 2009 is ChangeVue 2009, our very own Source Code Control System. Software developers are usually familiar with this type of application, but system and network administrator are not always aware of the benefits of this type of tool.

In the  following post I will attempt to point out the general use and benefits of source code control as well as some of its general principles. In future posts I will go into more details about ChangeVue.

A. What is it really?

The name “Source Code Control System” or the often also used “Version Control System” or “Revision Control System” do not really describe the three main functions of it.

1. Access coordination
2. Source code backup
3. Version storage of source code and other files.

Typically a repository or database serves as a central location to store information. For most situations this is usually located on a network server or on a NAS (Network Attached Storage) device. Storing the repository on your local hard drive is usually not such a good idea, as it defeats the backup aspect and removes access to the repository for other team members when you shutdown your machine.

A designated local folder, often called a ‘sandbox’, holds the local copies of files in a project. “Project” in this context means any number of files in a group, usually stored in a single folder or folder structure. It does not have to be a Visual Studio or other IDE project file, it’s just a term used to describe a grouping of associated files.

B. How does this access coordination work?

The usual process of working with a file under source control looks like this:

1. Check-out the file, which marks it as “in use” in the
   system, copies the latest version to your local working folder,
   and removes any existing read-only flag from the file.

2. Edit the file with whatever software you use for that specific
    type of file.

3. Check the file back into source control, copying the modified
    version to the repository, setting the read-only flag on your
    local copy of the file.

While user A has the file checked out, user B gets an error message if he attempts to access the same file for writing. This is called an “exclusive checkout”; only one user at a time gets access to a file to write to it (edit).

Although some systems allow a “concurrent checkout” which merges files as they are checked back into the repository, we will only cover exclusive checkouts for now.

The read-only flag is usually used on the local copy of the file to prevent unwanted file modifications without checking a file out. In most cases, it also serves as the trigger mechanism for editors to see if a file is under source code control.

In short, the check-out, edit, check-in cycle allows coordinated work on files shared among team members and prevents unwanted overwrites. Any popular IDE or code editor usually supports a variety of source controls systems and makes the check-out and check-in part as automatic as possible.

C. How is this a backup?

The central repository for a Source Code Control System (SCCS) is usually located outside of your local computer.

That effectively creates a backup of every file you edit and check in. Most types of SCCS applications allow you to completely wipe out your local work folder and restore it with the latest versions of all files associated with this “project”. This is also a very convenient mechanism to restore your development environment on a new computer.

D. How does it store versions and why do I want that?

Versions are (usually) stored by analyzing the checked-in file against its previous version and storing only the differences. That saves a lot of hard drive space, especially for binary files which are also subject to difference only storage.

Think of it as only saving the modified records of a database but not the ones that remained the same. How this internally works is not really important for the purposes of this article. What is your main benefit is that you can retrieve any previous version of your code or files very easily.

Sometimes you mess up and you must roll back changes you made in that last all-niter because you were actually too tired and typed a lot of nonsense.

Sometimes we have to refer to a version of code months back to determine when a specific bug was introduced and what changes where made (and by whom) to cause this.

Last but not least, sometimes someone else messes up and we need to be able to easily retrieve a last known good version of a file.

In short, it is belt and suspenders approach even if you only work by yourself and the team aspect does not apply to you.

E. What’s next?

In the next few posts I will use ChangeVue 2009 as an example on how to set up a working environment with source code control. I will also introduce you to the interactions and interfaces with IDEs and editors, specifically with PrimalScript and Visual Studio.

Those posts also will have big screenshots and less to read 🙂