An Overview of Source Control in Visual Studio Team System
This article provides an overview of source control used in Visual Studio Team System (VSTS). Source Control in VSTS does not only standard version control task but also provides very important link between the Team Project which is managed by VSTS and the technology solution which uses Microsoft .NET. Fig.1 shows how this link is formed.
For every source code item which we create as part of technological solution we can add a work item. This work item will be used to track how that source code item is progressing by checking its status time to time and then create reports on it. In addition to providing such integration, features of source control include
Before we delve into features of source control of VSTS, let us understand some commonly used terms:
Workspace: It is a physical area on the computer where user is working, which is used to store source code temporarily while the user is working on it. Every user has its own workspace.
Check-out: Getting a copy of source in the workspace to work upon it. VSTS source control supports multiple check-outs which mean that two or more users can simultaneously open a source file for editing.
Check-In: Sending the checked-out copy of the source file back to source control from the workspace. If file is checked-out by multiple users then for the first user to check it in, the operation always succeeds. For the subsequent users, if some conflicting source code area is detected then that user is prompted to resolve conflict either automatically or manually through the conflict resolution tool.
Check-In Policy: These are the actions users should take while checking in any source file.
Changeset: When some files are checked out, all the pending changes in them are identified with a common tag called changeset. Concept of the changeset provides atomic check-in for all the pending changes. It also is used to roll back the source files to a particular changeset before which the system was stable.
Let us now understand how to work with the Source Control.
Normal Version Control
Every resource is part of a team project. If we want to access a resource, we need to open the team explorer and connect to the required team project. After connection is established, we can open the “Source Control Explorer” to view and navigate in the source control of that project.
Check-Out a resource
We can check-out a resource by either double clicking on it or selecting “Get Latest” from the context menu.
Whenever user attempts to check-out any source code file, VSTS checks if a workspace for that user exist or not. If it does not exist then it prompts user to provide a path of the folder which will work as the workspace for that user. Workspace is owned by that user.
When the check-out is successful, the resource is copied into the workspace of that user and is available for editing. Whenever user makes any change in the resource, it starts appearing in the list of “Pending Check-Ins”.
After any file is checked out, we can lock it in different ways. By default file is not locked by default. We can place either a Check-Out lock or a Check-In lock. Check-Out lock ensures that no other user if not already checked out, will be able to check out that file till we check in. Check-In lock implies that no other user can check in file even if they have checked out that file earlier till we check in that file.
Check-In a resource
When the editing of the resource is over, user checks the resource in. If there are multiple resources which are pending for check-in then one check in action will club together all the resources as a changeset and the entire changeset will be attempted to be checked in. If any resource fails to be checked in then the whole check in process for the entire changeset is rolled back.
If it is found at the time of check in that the resource has been modified by some other user while we were editing it then as a first action it will be attempted to merge both the versions automatically. If there are no conflicts between the modified code in the source control and edited code in workspace then this succeeds. If automatic conflict resolution fails then Conflict Resolution tool makes it possible to do manual resolution of the conflicts. It shows two panes in which both the versions of the document are displayed. We can mark the code to be retained in any of those panes and complete the manual resolution of the conflicting code.
If we need to implement compliance to certain policy to maintain quality of code, source control provides the feature of Check-In Policy. There are three check-in policies which can be toggled off (Default) or on. Those check-in policies are:
Customized check-in policies can also be created and activated.
Branching and Merging
VSTS source control provides the branching feature as part of the overall version control solution. Need for branching is felt when we want to work simultaneously on two different versions. For example take a case where we have created a baseline solution of a standard product and do not feel need to modify it but at the same time a change suggested by a customer needs to be incorporated in it as a customization for that customer. Since this change is not required for standard product but is required for a customized version only we can create a branch for custom version. When we create a branch, it creates a copy of all resources as a branch of original solution from selected node downwards. It is now possible to edit both, the trunk and the branch to be separately. While some developers may be working on the trunk to enhance some feature, at the same time, other set of developers may work on the branch to create customized solution required by the customer.
There are other cases like working on multiple localized versions, working on some features which we are not sure can be implemented etc. where branching will be useful.
Fig. 4 shows the Source Control Explorer in which a branch of a main source is created.
When editing is over we can separately compile the branch and create a build of the total solution with that branch as separate version of the product.
Once the branch is compiled, we can merge it with the trunk or other branch. We may also permanently retain the multi branched, multi version solutions in the source control. While the merging is taking place if, both the branches are separately and simultaneously edited, we will again have to work with conflict resolution tool.
Shelving and Unshelving
Sometimes we are required to suspend the work in hand for some time. If we retain those resources in our workspace its security and reliability is very less. We would like to keep those resources in the source control but are not interested in checking it in. Check-In will mean that those resources will be considered for build but since they are partially completed they may not compile.
In such conditions we will prefer to shelve the work and later on when required unshelve it and work upon it. Shelving and Unshelving is a unique feature available only in VSTS.
Another use of shelving and unshelving can be to pass the code from one developer to another. One developer may have a half completed project and cannot complete it due to some reason. That developer will shelve the source code and ask another developer who is going to work further on it to unshelve it and start working on it.
A label is a marker that we can attach selectively to a set of otherwise unrelated files and folder versions in the source control to facilitate their collective retrieval to a workspace for either development or build. A common type of label is a milestone label such as “Beta 1” or “Release Candidate 1” etc. Labels can be applied in conjunction with operations like branching, merging or getting specific versions of files and folders etc. Labels are un-versioned which means that no history of files or folders were previously marked with a label is not maintained.
Going back to earlier version
Whenever some resource is checked in, it is given a changeset number. Changeset is a logical container for all resources which are checked in at the same date/time. Every details and historical data related to every changeset are retained by source control. In case we need to roll back to an old version, we can find a changeset which represents the version which we are interested in. When it is found and selected we are shown the Get dialog box. Get retrieves the files which were checked in as that changeset. It optionally overwrites the files which are in the workspace.
Visual Studio Team System provides robust, feature rich and scalable source control. All the tasks for version control and many more can be conducted through source control. It provides some new features such as changeset and shelving – unshelving in addition to traditional features of check-out, check-in, locks, branching, merging and labeling.
I hope you liked the article and I thank you for viewing it.
If you liked the article, please subscribe to the RSS feed over here.
This article has been editorially reviewed by Suprotim Agarwal.
C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.
We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).
Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.
Click here to Explore the Table of Contents or Download Sample Chapters!