Version Control in VSTS 2008

Introduction

Version Control is the most integral part of software development. All of us use version control systems in some form or the other. As part of my article series on VSTS 2008, let me share the version control features available with VSTS 2008 in this article. Version Control is one of the elements of Team Foundation Server apart from Work Item Tracking, Project Management, Build Automation and Reporting.

Comparison with VSS (Visual Source Safe)

VSS was the predecessor of the TFS Version Control. However, the TFS-Version Control is not a version of VSS. TFS-Version Control is build group up. Before getting into more depth of the Version Control feature of TFS, let me put up a brief comparison between VSS and TFS-Version Control.

Following are the version control features that are not available in VSS, but available to TFS-Version Control system:

• Workspaces
• Changesets
• Shelvesets
• XML Diff/Merge Tool
• Content Merge, Namespace Merge (branch)
• Auditing
• Locking

VSS uses File System as storage whereas TFS-Version Control uses SQL Server 2005 / 2008 as storage. However it is possible to migrate the source safe from VSS to TFS-Version Control. Also TFS-Version control is tied up with the active directory for security.

Features

The key features of TFS-Version control are as follows:

Workspaces

Workspace is a Client Side copy of the source checked out from the server repository and is owned by one user on one machine. Workspaces can also be referred to as working folder in the user’s terminal. Any change in the workspace actually creates “Pending Changes” to the server.

Changes in workspace create "Pending Changes".

Changesets

Changesets can be treated as a Logical container of data related to check-in. With check-in, there is a lot of data transferred to the server apart from the files being checked in.
Changesets consist of:

• File and branch information
• Link to work items
• Check-in notes
• Comment
• Policy compliance
• Metadata (date, time, user)

Changesets are uniquely identified by numeric numbers and are incremental with every check-in to the server. Any check-in to the server from the client will have the above listed items based on the setup / configuration on the TFS for the project.

Locking

Locking is a feature in TFS-Version control system that can be applied to a file or folder. There are various types of locking as listed below:

• Checkout Lock, lock that prevents other users / contributors from checking out a branch or file.
• Check-in Lock, lock that allows checkout, but not check-in. Allows others to work with a file, but not check in.

One lock is allowed per file or folder.

Labels

This is one interesting feature that allows users to put in a label to a selection of files from different branches.
Example: Milestone like Beta2 applied on a collection of file/folders.

Branching

Branching is one of the most important features using which we can take out a version from the source control. Many a times, we may need to take out a version of the application for release and maintain the release version as a separate copy. In such scenarios, we can branch out from the source control and store it separately.

Merge

Merging works in tandem with Branching. Using this feature, we can merge or sync a branch into another branch.

Shelving

Shelving is one of the most important and interesting features available with TFS-Version Control. Many a times, we need to keep our work done separately without updating the version in the server with check-in. With shelving, we can actually store our changes in the server without checking in the changes in the server. Say, one team member is working on a set of files and the team member could not achieve the successful compilation for the set of files and the she is going on leave. The team member will have to check in the files back to the server and with this mid way change, she cannot check-in and also if she performs undo check-out, her work will be lost. Shelving is a solution in such cases, wherein she can shelve the files in the server and perform a check-in on the initial version and later get back the shelved version from the server and complete her task.

Shelveset is the result of shelving.

• A special version of changeset stored in the server as temporary workspace
• A check-in of "pending changes" set aside for later usage
• Can be retrieved later by the creator and / or other team members

Scenarios of usage:

• Share a work in progress with another team member
• Code review before finishing current tasks
• Put an incomplete effort on the server for backup
• Put aside an effort because a higher priority task arrived

Parallel Development

With TFS-Version control, we can do parallel development through:

• Multiple Releases, through Branching (Create a copy of a set of files for a separate work effort) and Merging (Combine the changes in one branch into another branch)
• Multiple checkouts, files can be checked out by multiple developers and later, the changes can be combined.

Check-In Policy

In TFS, we can define a check-in policy for any project. With check-in policy, we can achieve the following objectives, which are usually bound to the organizational process:

• Can enforce builds - requires a build with no errors with every check-in
• Unit Testing - requires usage of Unit Testing with every check-in
• Static Analysis - requires a clean run with the Code Analysis Tool on the code files being checked in
• Work Items - requires association of Work Items with every check-in
• Multi-checkout - files can be checked out by multiple users

Conclusion

I have tried to cover the most interesting features in TFS-Version Control system. However this does not cover all the features. You can get into the core, only by working on the Version Control system and hope you will also enjoy while working on the TFS-Version Control. You will find that lots of Configuration Management issues are resolved in your project.

History

• 24^th August, 2009: Initial post