Wrox Home  
Adam Kolawa - Co-Founder and CEO of Parasoft
Adam Kolawa is the co-founder and CEO of Parasoft. Kolawa, co-author of Bullet-
proofing Web Applications
(Wiley, 2001), has contributed to and written hundreds of commentary pieces and technical articles for publications, such as The Wall Street Journal, CIO, Computerworld, Dr. Dobb's Journal, and IEEE Computer. He has also authored numerous scientific papers on physics and parallel processing.

Making Your Source Control System Work for You

By Adam Kolawa, Co-Founder of Parasoft

To get the most out of your source control system, apply the following guidelines across your team.

Each developer should have a sandbox with copies of files related to his or her current work
A sandbox is an area where copies of project-related files can be stored and manipulated without affecting the master source code base. The team should establish a developer sandbox for each and every developer. In addition, each developer sandbox should be shadowed (that is, be updated to match the new/updated/removed master files) from the source control system regularly, and cleaned after major revisions (see the section, "Each developer should clean the sandbox and re-shadow relevant files after major changes").

The build process should have a sandbox with copies of all files needed to build the application
The team should establish one build sandbox for each system that the team needs to build. Every day, the build sandbox should be cleared, then cleanly shadowed (that is, be updated to match the new/updated/removed master files) from the source control system. Ideally, once the build sandbox is established, it is used according to the build policy guidelines that will be described in an upcoming column.

Each developer should check out only the code that he or she is actively modifying
Before a developer can modify a file that has been "shadowed" to his sandbox, he should "check out" that file from the source control system. After a file is checked out, it is locked to that developer, and nobody else is allowed to modify that file until the first developer "checks in" his changes (that is, adds the modified file back into source control and removes the revision lock). During any given day, each developer should check out only the files that he is actively modifying. When team members lock files that they are not actively modifying, they may be preventing other team members from modifying the files that they need to work on, and thus causing a development bottleneck.

Each developer should add to source control only the code that complies with the required practices and passes the designated quality checks
As soon as a developer is certain that new or modified code satisfies the team's designated quality guidelines, he should add that code to the source control system. When developers work in this way, the only code that is not available in the source control system is the code that a developer is actively modifying.

These first four source control policies are illustrated in the following figure:

Click for full size image

Each developer should clean the sandbox and re-shadow relevant files after major changes
After significant structural changes are made to the directories shadowed in a developer's sandbox (for example, after many files are added, removed, or renamed), it is a good practice to remove all files from the sandbox, then re-shadow the code. This ensures that the sandbox is in synch with the related area of the source code repository. The build sandbox also undergoes a similar cleaning to ensure that it too stays in synch with the main source code base.

The entire team should store code for different software versions in physically independent source control systems
After the code for a software version receives the stamp of approval, it should be physically separated from the working code base and placed in an independent source control system. By physically separating the code base for each "final" software version, you remove the possibility for day-to-day source code modifications to impact "final" versions of the software, and you also prevent any emergency fixes to that "final" version from affecting the current version. When a version is no longer supported, the entire source control system for that version should be archived and stored.

For example, assume that your team just completed version 2.0 and is now ready to modify the code to add new features for version 2.1. Before you start modifying any code, you should place the complete 2.0 code base under an independent source control system. This way, you will always be able to reproduce and - if necessary - modify the true version 2.0 code base.

Click for full size image

If you do not work in this way, you will be taking two serious risks:

  • If you fix a file in the old version of the software, you could cause unexpected side effects in the current working version of that software.
  • As you modify files in the new version of the software, your changes could impact the old versions and you could end up not knowing exactly what code is being used in the old versions.

The entire team should use versioning features only for slight variations within one software version
Many developers are under the impression that versioning features allow them to safely maintain and modify different versions of code. But what they don't realize is that errors may occur because modifications are sometimes made without paying close attention to version numbers. A developer may fix a problem in one version, while creating numerous errors in another version.

These versioning pitfalls can be averted by moving each completed software version's code base into an independent source control system, as described in the preceding section "The entire team should store code for different software versions in physically independent source control systems."

Although versioning features are typically error-prone when used to separate code from different sequential releases (for example, 2.0 from 2.01 and 2.1), versioning features could be useful when you have minor differences in a software version (for example, different versions - with slightly different files - for different devices or platforms).

The entire team should always avoid the parallel development feature
The parallel development feature in many source control systems allows multiple developers to work on the same file simultaneously. After each developer makes his respective modifications to the file, he checks it back in, and the system is supposed to merge the multiple modifications. However, it typically does not work well in practice. In reality, bugs are often introduced because the system is merging two or more very different pieces of code that were modified without regard for each other. Therefore, you should block this feature from your source control tool, and establish guidelines that allow code to be modified by only one developer at a time.