Source Control Basics: Shelving, Branching, and Merging

As you probably know, Microsoft recently released Team Foundation Server. TFS lets developers manage the check-in and check-out of source files from within Visual Studio 2005. In addition to its role as a developer collaboration portal, TFS is the integrated source control server for Team System. In this capacity, TFS provides three features for managing source code:

Let's take a look at these source control options and see where they fit in your software development process.

Related Update: Two Sides of the Same Coin

Compared with Visual SourceSafe (VSS), shelving is a new feature that lets you easily follow a best practice: checking in your code changes on the server at the end of each day. Backing up your changes ensures that you don't lose your work because of a hardware failure or another type of failure. However, this practice poses a problem in that a developer often works on a set of code changes that aren't complete by the end of the day. The code involved won't build much less run--and when it's checked in, problems in the code might affect other team members who attempt to retrieve that same source code. As a result, while most organizations talk about checking in changes every day, those organizations using VSS rarely implement it.

Shelving alleviates the problems posed by having a daily check-in. With TFS, you save a copy of your current changes to the source control repository at the end of the day. However, as part of this process, you indicate that the source code isn't ready for others to retrieve. The code is put on the shelf, so to speak. Only you will be able to access the shelved version. That way, your daily changes to the source code are backed up, but other team members won't be able to access the unfinished code.

Shelving is a obviously a great way for one developer to back up his or her changes in the source repository, but what happens when more than one developer needs to access or work on the same source code? This is where the concepts of branching and merging come into play. The idea behind these concepts is that at some point you might need to have more than one copy of a source file.

One reason why you might need more than one source file is if you have different versions of an application. For example, when you begin to work on version 2.0 of an application, you might want to keep a copy of the version 1.0 source files. That way, if someone finds a bug in the version 1.0 code, another developer can check out the version 1.0 source files and repair the bug. Because the version 1.0 source file isn't being worked on for new development, there's no risk that some incompatible version 2.0 code will be caught up in this bug fix. Then, as you work on version 2.0, you can determine the best solution for that version, given the other changes occurring in the application. In many cases, the version 1.0 bug won't be reproducible in version 2.0 due to other changes, so the fix won't be needed.

Microsoft appears to follow this practice internally. If you've participated in a beta or release candidate (RC) program in which there are interim releases, you know that Microsoft branches a code base in preparation for a release. For example, the branched code for a beta 1 version might have several last minute patches to work around unfinished added features, even as the newly branched source files are modified in preparation for beta 2.

In this scenario, branching is a best practice because it doesn't involve merging change sets. Merging is a way of attempting to combine changes made to the same source file by two different developers. Some organizations use merging, which is why it's supported. However, automatically merging changes from different developers is definitely a risky process. Here's why. Suppose developer A worked exclusively on method A and developer B worked exclusively on method B. In this case, the automated merge process is simple in that Developer A and Developer B worked on separate lines of the source file. However, this simple type of merge is the exception and not the rule.

What happens when developer A and developer B make changes to the same method for different bug fixes that overlap logic within that application? There's no reliable automated process for merging changes on the same line. Merging changes will always require some level of human intervention and additional testing because when changes are merged, the resulting code might fail to build or develop new problems. Thus, although TFS's merging tool can be helpful in rolling a change from version 1.0 to version 2.0 of an application, using it in an active development cycle on a single version of an application is risky.

For more information about shelving, branching, and merging, check out the following Web pages: