Unlike Visual SourceSafe (VSS), which relied on a file-based storage mechanism, Team Foundation version control stores all artefacts, as well as a record of all changes and current check-outs in a SQL Server database which makes it highly reliable and scalable. It supports features such as multiple simultaneous check-outs, conflict resolution, shelving and unshelving, branching and merging, and the ability to set security levels on any level of a source tree, alongside the most visible features of document versioning, locking, rollback, and atomic commits. The source control mechanism integrates with TFS Work Item Management as well. TFS administrators can enforce check-in policies that require specific requirements to have passed and individual versions of files can be assigned labels. This session is targeted towards developers who want to know all the details about the new version control features in Team Foundation Server 2010.

Read more.

Update [May 4, 2011]: recording uploaded to Channel9

Watch recording

Apart from the fact how this “build automation” should be called, there are many reasons why you should enforce this behavior on different branch types for your applications. The ultimate goal is to improve the quality of the software application and to reduce the time to release the application in production. By setting up early validation (compilation, automatic testing + other quality gates) through “build automation” you will at least be notified as soon as possible of all kinds of validation errors (= quality check) and you will have a chance to fix them before other team members will be impacted by pulling a get latest on the repository.

Automatically firing a validation build after a check-in will in the end not prevent broken builds and that’s where the Gated Check-in Build will come into play with Team Foundation Server 2010.

The Gated Check-in Build in TFS2010 will prevent broken builds by not automatically committing your pending changes to the repository, but the system will instead create a separate shelveset that will be picked up by the Gated Check-in Build. The build itself will finally decide if the pending changes need to be committed to the repository based on the applied quality gates.

The picture above describes the full process of a Gated Check-In build.

How to setup a Gated Check-in build?

The Trigger Tab in the Build Definition window has now an extra option for selecting Gated Check-in.

At the moment a check-in is attempted by a developer in the branch where the Gated Check-in build is active, the developer will be faced with a dialog box.

Cancelling this window will not kick off the build, but will also not commit your pending changes to the repository. If you really want to overrule this build with committing your changes directly to the repository, you may select the 2nd checkbox to bypass the validation build (not recommended). By default your pending changes will reside in your local workspace (first checkbox). In the situation where you immediately want to start with new changes – not relying on previous changes – it might be appropriate to uncheck the first option.

In the ideal situation, the build will complete without any validation errors and will eventually commit the changes to the repository. This will also lead to a Gated Check-in notification for the original committer via the Team Build Notification tool.

If you had previously chosen to preserve the changes locally (default), you may have noticed that the files you were working on were still checked out during the build … and in fact after a successful build these changes do not reflect the as-is situation anymore of the repository. With the above window you get the option to immediately reconcile your workspace with the up-to-date repository. So, clicking the “Reconcile …” button will give you the opportunity to select the desired files to force an undo in your local workspace and to pickup the changes that were committed by the Gated Check-in build for these files.

Another way to reconcile your workspace (if you for example ignored this window or when the build notification is way too slow) is by right-clicking the completed Gated Check-in Build in the Build Explorer and selecting the option to reconcile your workspace.

If you did not choose to preserve the changes locally, there won’t be any changes to reconcile after the Gated Check-in build, even if you forced the reconciliation.

The Gated Check-in build may also be kicked off manually where you may need to create a shelveset or where you may point to an existing shelveset.

A last thing to note is that the comment that was originally supplied to the changeset by the developer will be suffixed with the NoCICheckinComment variable (default = ***NO_CI***) to prevent that another continuous integration build will be fired after the final check-in done by the Gated Check-in build.

Summary

What meant to be a small post on the Gated Check-in feature in Team Foundation Server 2010 ended up in a more detailed explanation of how it works and how you can work with it in the Visual Studio IDE. Remember that you should setup the most appropriate build types according to your specific branches. Not all branches may need a Gated Check-in build. Only configure this for branches that should never have a broken build. A Gated Check-in build may for example validate a big merge operation from a development branch to a stable main branch.

The session slides can be downloaded in the download section of this blog.

Watch recorded video (1 hour and 10 minutes) at Channel 9.

A demo on Branching & Merging with TFS2010 was the major part during the presentation and I did practically cover everything I wanted to share with the audience: Branch metadata, Fine-grained security, Branching Visualization, Tracking individual changesets across branches, forward/reverse integration … except for one little important merge action that I forgot to show!

After the creation of my dev branches (from main) I also renamed the solution in those dev branches with an additional suffix to avoid confusion while loading different solutions into Visual Studio 2010. This was done in changeset 121 and I renamed the solution from WebsiteSparkles to WebsiteSparkles_dev1.

Afterwards I did some code changes in the dev branches and pushed some explicit changesets back (Reverse Integration) to the main branch, using the cherry pick option in the merge wizard to avoid merging also the solution rename.

As a result changeset 121 will always remain a merge candidate in the Source Control Merge Wizard.

In some cases you really want to merge changes back to main on the latest version of the development branch without cherry-picking all required changesets. To be able to do that, you need to get rid of changeset 121 as a merge candidate.

This can only be done through the command-line with the tf merge /discard command.

This discard command will make sure that changeset 121 will not be a merge candidate anymore. Note that you still need to commit this action to the repository after executing the command. The discard command will only update your local workspace but won’t do an automatic check-in.

Next time you will run the merge wizard and look for merge candidates, changeset 121 won’t be listed anymore and you may merge from a latest version of this development branch for upcoming changes.

Providing this discard command from within the source control merge wizard would be a very nice addition!

But due to this entry in the TFS forum I was finally able to remove the Team Projects from Source Control Explorer as well.

Solution:

• Create new Team Project with exactly the same name as the Team Project that wasn’t completely deleted and specify the option to not create the version control folder.
• After the Team Project Creation wizard finishes, you need to run TFSDeleteProject.exe for the newly created Team Project.

No sign anymore of the deleted Team Projects in Version Control! Sounds logical?!

In the screenshot above you may notice that changeset 9 (dev branch) is merged to the main branch. But look at the yellow color of the bar after the merge and the tooltip that is shown when I hover over changeset 11. Changeset 9 consisted of 2 different files that were modified while the merge operation took only 1 modified file in changeset 11. Valuable information!

In TFS2010, a branch is now seen as an atomic operation: it doesn’t copy all files into your local workspace and the branch action is immediately checked-in – no option anymore to do some local modifications. The child branch will always be an exact copy of the selected parent branch folder. You will get a messagebox that will notify you of this action when you hit the branch button …

You will need to request a get latest on the newly created child branch to have a local copy of the sources.

Some simple changes can make a big difference!

Go the command prompt and use the tf diff[erence] command:

tf diff source /version:C22~C23 /recursive /format:unified > C:\Temp\diff.txt


• source is the name of the folder I want to recursively [/recursive] look up all differences
• /version:C22~C23 means that I want to find only the differences between changeset 22 and changeset 23
• /format:unified sets the output type to the Unified format derived from the UNIX based diff –u output format
• > C:\Temp\diff.txt sends the output to the diff.txt textfile

When finished open the diff.txt file in an editor that supports a difference scheme. In the example below I used Notepad2 to load the output file in the diff scheme.

The information written into the textfile is only the specific region in each textfile that’s different from the previous changeset. It’s a nice way to visually review only the portions of a set of files that were changed. It will save you a lot of time if you otherwise would want to review file by file via the GUI.

Your local workspace may not contain pending changes on files that are included in the shelveset. However, there is a way to unshelve with local pending changes. Therefore, you need to have the Power Tools installed for Team Foundation Server.

From the command-line you can execute the tfpt unshelve command with the name of the shelveset to accomplish that.

tfpt unshelve allows a shelveset to be unshelved into a workspace with pending changes. Merges content between local and shelved changes. Allows migration of shelved changes from one branch into another by rewriting server paths.

Like in a normal get latest scenario, you will be asked to resolve conflicts and eventually be redirected to the well known TFS merge window.

I have a Main branch and two feature branches that were both branched from Main. Now let’s assume certain changes are made to FeatureBranch1. These changes are merged (reverse integration) to Main and at a later stage a release branch (1.1) is split off to the Release folder (from Main). Some time later the code file is being inspected in the 1.1 branch (release folder) where the code change of FeatureBranch1 was executed. In the Annotate window [a new feature in TFS2008] you would be able to see that on line x a change was made by person y on time z. So far so good! The question that now pops up is : “What do you really want to see in the changeset details?”. The best answer of course is that you immediately want to see that those changes originated from the FeatureBranch1, but at this moment TFS2008 won’t provide you with this information. You will have to manually drill down the branch hierarchy to find out that this change came from a check-in into the FeatureBranch1 by person x. TFS 2008 only gives you the information (via the annotate feature) that the change came from a merge (Main branch). This is not ideal, because you will have to step into the history and dig deeper to find out the original changeset in FeatureBranch1.

TFS 2010 will come to the rescue in the future and will provide you with the details you are really looking for in that type of situation. In the tooltip of changeset 74, TFS drills down through all merges and loads the details of the initial check-in at FeatureBranch1. Note that the screenshot is taken in the source of code in the 1.1 release branch.

Right-clicking on the changeset 74 hyperlink will even give you the option to view the original changeset details of the FeatureBranch1 check-in or to view the history …

The history window as seen above will now give you a hierarchical view on how the changeset came into the release 1.1 branch. To top it off, you can also track the 74 changeset visually by right-clicking …

The first view in the screenshots below is a timeline view where you can follow the merge history of changeset 74 and the second view is a hierachical view where you can detect the hierarchical dependencies between branches.

Very nice features I wish I had already at my disposal right now …

One of the features of TFS2010 I like a lot and can’t wait to make use of in the future is the improved support for parallel development. In this post I would like to highlight the way branches are treated in TFS2010 …

First of all, branches will be treated as first class citizens. If you look at the next screenshot you can see that branches are now differently displayed in the Source Control Explorer with another icon.

Branches may be organized in folders and each branch has now its own special properties :

• General Branch Properties

  

• Relationships

  

• Permissions

  

Conversion to branches/folders can be executed via the context menu in the Source Control Explorer.

In a next post I’ll start exploring the new branching and merging possibilities, but before I close this post I would like to point you to the new TFS Branching Guide (2.0) that was recently released and contains a lot of essential information how to choose the best strategy for branching (and merging) your Team Projects. I like the way Jeff Beehler stressed the importance of having such a strategy :

Selecting the right branching strategy is one of the most important aspects of TFS deployment. Picking the right strategy can lead to optimized team cooperation, increased productivity and a successful adoption. On the other hand, selecting a bad branching strategy can cause frustration, damage productivity and derail TFS adoption in an organization.