The move from Team Foundation Server (TFS) 2012 to TFS 2013 and Git is not a simple one. In our transition to open source, we decided that Git as a version control system would much better suit our needs. Using Git internally makes our workflow with the Warewolf Easy Service Bus (ESB) Github repository seamless.
We used TFS 2012 and Team Foundation Version Control (TFVC) internally to manage our code-base and our Agile sprints. It generally works pretty well as an internal tool. TFVC has its drawbacks, but as a developer one can live with them.
The post-Ballmer era has seen a large cultural shift happening within Microsoft. Under the new leadership of Satya Nadella, Microsoft now contributes extensively to open source, and they use Github as their primary public repository. One of the major changes is Microsoft’s real commitment to openness , and their commitment to Git is no exception. At least five Microsoft employees have contributed to libGit2 which is a portable, pure C implementation of the Git core methods provided as a re-entrant link-able library with a solid API.
Git with TFS 2013
One of the key features of Git is its portability. For example, one can put a repository on a flash drive, work remotely, and from the flash drive commit changes back to the main Git repository. But in true Microsoft style, they have not created a pure standards based implementation.
Microsoft, version of Git stores the repository in a SQL Server database, like TFS, which defeats many of the benefits of Git. Sure, the pulled version is fully compatible with the Git protocol, but the server implementation still breaks the standard.
I can see why they did it. The main reason was to maintain a decent level of compatibility with the rest of TFS, including the build and project management features. But they could have put in a little extra work and done it right the first time.
No official migration tools
The real bugbear in the migration process is the lack of official TFSVC to GIT repository migration tools for TFS. In short, there are none. The result of Microsoft’s short sightedness is that it is nearly impossible, bar writing your own conversion system, to cleanly upgrade a TFVC repository to Git on TFS. There have been some valiant efforts by independent developers but the code bases have not been maintained… Tightly coupled with the TFS repository was the agile project management system that Microsoft provides in TFS. The lack of an official migration tool meant that we were going to lose our trackable history.
The best we could do at this point was to migrate the work items separately, which is what we ended up doing. We decided to keep our existing TFS repository for historical purposes, and to only migrate the current work item backlog.
Why we chose to migrate TFS to Git
Our main objectives of our migration to Git, was to move our primary repository (the Blessed Repository) to Github during the technical migration of our open sourcing effort. Fundamentally this meant that our main repository would no longer reside with the core development team. It made sense for our local repository to be a Git repository too.
Having our new workflow now centered on the GitHub repository, and the inclusion of community developers as part of the Warewolf ESB development ecosystem, also meant that we had to include a system for handling Git pull requests that included a code-review and a run through the testing regime before being merged into our local repository.
Maintaining the integrity of the Git Blessed Repository
By rule, the only code that we commit into the Blessed Repository is done from the repository that resides with the development team. That way we can ensure that the integrity of the Blessed Repository remains intact.
Migrating from TFS to Git
The team at Git-tfs have built a sterling product with which a TFS can interact with a Git repository. Git-tfs is great. It can be used to sync a TFVC repository with a Git repository. The tool is fairly comprehensive, but there is not full compatibility. We needed more in our workflow.
As an open source project, our community developers are using our Git repository, so it made sense for us to all be on the same platform so that we could begin to take advantage of the full set of features offered by Git.
Our TFS build and testing environment
We have an extensive, scalable build and testing system to ensure that the versions of Warewolf ESB that get released are rock solid. We have invested extensive resources in this environment. So we needed to maintain our TFS infrastructure because our build and testing infrastructure is currently centered around TFS. Migrating to a TFS Git repository for our core development team was the logical choice. We could retain the functionality of TFS build while taking advantages of what Git has to offer.
TFS 2013 works well with Git, and with each iteration, Microsoft are releasing more Git-centric updates for the development environment. Microsoft are clearly committed to Git, but they are also committed to the rest of the TFS product range, and they all use a data centric model. So I can see why Microsoft chose to deviate from the standard again in this case. Hopefully at some point in the future they will take the bold move of making Git file system based, as it is meant to be.
The upgrade path we followed
- Upgrade all of our development environments to VS2013
- Install the Git tools on our development workstations
- Upgrade TFS 2012 to TFS 2013
- Create a New Git Repository on TFS 2013
- Export the TFS repository to a local Git repository using Git-tfs
- Import the local repository into the newly minted TFS 2013 Git repository
- Migrate the backlog Microsoft Excel
In short, the process was not as painless as we had initially hoped it would be. It would be really helpful to the development community if Microsoft put some effort into ensuring that TFS was compatible with itself. I suspect that they will do so in the future, but in the meantime we are left to fend for ourselves. I hope that this series of blog posts will help to simplify your own migration if you are currently planning to do so.
In part two of this blog, I will get into the technical details about the migration process. I look forward to your comments.
Leave A Comment?