Distributed Version Control with Team Foundation Server 2012

This is the presentation Thorsten Ruf and I gave at the Microsoft Techdays 2012 in Basel. Enjoy!

Microsoft Team Foundation Server 2012 is a modern Application Lifecycle Management Platform. As such it offers more than just version control but also necessary tools such as requirements management, issue tracking, process management (i.e. for Agile processes such as Scrum), testing infrastructure and build capabilities to name a few. Unfortunately many flame wars which compare TFS against other products are only based upon TFS source control capabilities and completely ignore the other exciting features this platform offers, especially in the 2012 release version.

So what is all that ranting about TFS source control capabilities? Let us look into some of the common rants people shout out on the internet:

People claim that there is no real offline support. When people talk about offline support they usually mean the capability to do local commits, local branching and to have a local history without having to connect to the TFS source control for nearly every operation. Latency by using the always connected model seems to be the major issue.

People claim that the merging capabilities are rather limited compared to other version control systems (VCS). Especially when several people are working on the same project and therefore changes happen often. Things like tracking of renamed or moved files seem to be problematic according to the rants. Besides people dislike that with server workspaces all files are read-only which seems to interfere with available build tools on the market.

In collaborative and open environments people tend to use multiple tools which do not have a direct integration into Visual Studio. Imagine you want to change your build scripts with your text editor of choice. Change tracking becomes complicated and error prone if you are working outside the standard toolbox.

Especially in the open source world people lack the ability to create real source patches and send them, for example via email, to collaborators. They claim that shelving is to heavyweight for that purpose. Are these rants even true?

Some of the rants such as the ability to work offline could be argued against by pointing out the new features such as Local Workspace of Team Foundation Server 2012.

Surely you all have already heard about that. With this new feature, we get rid of these annoying read-only files and have subversion-style behavior. What do we get more: a local history… sorry, not really. It is the last version received from the server which is stored separately, so we can diff/revert our local changes. Ok, that’s a good step. In combination with the usage of asynchronous functionality we can now start working immediately with the files in our solution. There is no latency anymore, because the checkout is done asynchronously.

Who has already seen the new Team Explorer inside Visual Studio? Have you tried to edit for example your nant local build file outside of Visual Studio? Hey… We have done it!

With the local workspaces we also get a very nice detection change mechanism. In the new “my work view/pending changes”, there is a new area for the automatic change detection, include the detected change into your pending changes and go for the check-in.

Another major improvement we get on the merge behavior. With the introduction of the local workspaces the experience really had to improve and Microsoft incorporate a lot of feedback from the community to make it better. They took a closer look on Git and could really improve their “merge-engine”. A lot of merge conflicts can now be solved “automagically”. But we think they could not fulfill all of our needs. There is still this really, really choppy merging of major refactorings, which we are doing every sprint and it takes us a lot of time to get it merged manually.

It doesn’t matter if you are working in a small team of a few people or if you are working in a more collaborative project whose contributors are spread over various geographically separated locations. As the business grows and the software needs to be adapted to new customer needs large refactoring, redesign or multiple contributors working on the same behavior, are just around the corner.

That is usually the case when distributed version control systems (DVCS) come into play because they are designed from the ground up with a completely decentralized model and have very strong capabilities in merging and working in occasionally connected environments. One of the most popular open source DVCS is a tool called Git. Git has answers to a lot of the rants already mentioned. Let us dive into the capabilities of Git as source control system and then come full circle in how we can combine the strengths of TFS with the strengths of Git.

Before we start talking about the fundamentals of Git we first look into a brief history of VCS so that we know where we come from.

Currently there are three VCS generations available. Let us explore the characteristics of each generation!

First Generation VCS such as Source Code Control System (SCCS) and Revision Control System (RCS) only allowed to version a single file. Concurrent development was handled solely with locks. Only one person could be working on a file at a time.

Second Generation VCS such as Concurrent Versioning System (CVS), Visual Source Safe (VSS), Subversion (SVN), Team Foundation Server (TFS) and Perforce allow to version multiple files and follow a centralized model. Having a centralized model means that you can check out all files from a particular repository from a specified version. That model is a fair bit more permissive about simultaneous modifications, with one notable restriction: Users must merge the current revisions into their work (local working copy) before they are allowed to commit (merge before commit).

Third Generation VCS such as Git, Mercurial (Hg), Bazaar and Bitkeeper work on the notion of changesets and not files and follow a completely distributed model. Changesets can be shipped around which allows to have both clients and servers to have the entire repository including the history present. This allows completely separating the merge and committing operation (commit before merge).

Having a DVCS has several advantages. We can have different topologies with a DVCS in place.

It allows having a centralized model in which developers work on their own repository but push their changes to one central repository. This can be typically found in enterprise development.

A hierarchical model can also be used in which developers have their own repository but push their changes to subsystem-based repositories which are periodically merged into a main repository. An example of this model is the Linux kernel in which subsystems such as graphics, audio and more are developed and pushed to their own repositories.

Finally there is the distributed model in which developers push changes to their own repository and project maintainers pull changes into the official repository. This model is often found in open source development on platforms like Codeplex or Github. Another major advantage is that backup becomes extremely easy. Each clone is a full backup of the entire history of a repository. Because DVCS are made for distributed models they offer powerful and reliable branching and merging capabilities online and offline. Branching and merging operations are extremely cheap and fast. This allows for example having feature branches and always be working under version control. Having the full local history offline enables the computation of repository statistics locally or event analyze regressions such as when a certain bug was introduced by a changeset (i.e. with the git bisect command).

Git was created by Linus Torvalds who also created Linux. The creation of Git was born out of need because Bitkeeper, their previously used DVCS, didn’t provide free licenses anymore to the Linux contributors. Git is written in Perl and C and the development started in 2005.

The design goals of Git are speed, simplicity, strong branch/merge support, distributed and well scaling for large projects. In the beginning it was primarily used by the Linux kernel developer community. Although it was designed for Linux operating systems there are a variety of packages available for other platforms such as Mac OS and certainly Windows.

Let us see a common workflow as a live demo how a developer would work with Git under Windows. The workflow guides you from installation up to small development cycle and will explain common and mostly used Git terminology.

Now that we know what advantages Git can offer how do we combine those features with the powerful features TFS provides us? Let’s bridge the two worlds together!

With tools called integration bridges it is possible to bridge between TFS and Git in both directions. The major players are a tool called Git-TFS and the recently released Git-TF bridge from Microsoft. Today we will focus on the Microsoft tool Git-TF which was first announced on August 13th and can be downloaded on Microsoft popular open source hosting platform codeplex.

Git-TF is a set of command line tools that facilitate sharing of changes between TFS and Git. These tools make it easy to clone sources from TFS, fetch updates from TFS, and update TFS with changes committed locally in Git.

Imagine what this offers us! We can now combine the centralized model of TFS where we put our issue tracking, build and integration platform with the distributed model of Git. Suddenly we have a centralized enterprise integration platform where the product actually gets assembled and prepared for shipment combined with the ability to work, merge and branch offline with peers in a distributed fashion. Unbelievable? We show you how it works in the demo!

Wait! There is even more exciting news! Git-TF is based upon the Team Explorer Everywhere model and runs on the java runtime environment. Therefore it can be used on various platforms such as Linux, Mac OS X, Solaris, AIX or HP-UX machines. You see: Git-TF is a cross-platform tool set and can be used not only for Windows development! Leverage the powerful cross-plattform features of Git and combine it with the amazing features of Team Foundation Server 2012 and never feel restricted again!

All images used in the presentation are either licensed by istockphoto.com or sxc.hu. The used icons are from iconarchive.com. If you want us to give this presentation at your conference or user group just contact either Thorsten Ruf or me by email (firstname dot lastname at bbv dot ch).

Sources include:

Brian Harry’s blog – Announcing Git Integration with TFS

Locking and git-tf and… danger?

Building iOS Apps in TFS

History of version control

Oren Ranting about TFS (see comments)

Roy Osherove answering

This entry was posted in .NET, Events, Presentation, Speeches, Team Foundation Server and tagged , , , . Bookmark the permalink.

2 Responses to Distributed Version Control with Team Foundation Server 2012

  1. Aarsh says:

    Short and Sweet ! I actually have a question :

    I love – DVCS – the way GIT is. But at work we are using TFS server and is hosted by us. Is there a way for us that we can use GIT like local and remote repositories and still use Team Foundation Server ? I tried to look on internet but all I could found was TFS Service – hosted by microsoft, we are using our local TFS server.

    I can be reached at aarshstalati1989@gmail.com

  2. I constantly spent my half an hour to read this web site’s articles
    every day along with a cup of coffee.

Leave a Reply

Your email address will not be published. Required fields are marked *