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:
Shelving, which is a new and much needed feature
Branching, which is helpful in specific situations
Merging, which should almost never be used
Let's take a look at these source control options and see where they fit in
your software development process.
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:
Shelving: http://msdn2.microsoft.com/en-us/library/ms181283.aspx
Branching and merging: http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
End of Article
