Git - TFS Integration - Options
For the second part of the series, I’d like to discuss some of the options we thought of and why we said no.
More Background
In addition to our source control systems, we have a Continuous Integration server that runs before checkin. We use TFS’s shelveset feature to submit items to the CI server, then it does a tf checkin when it verifies the shelveset.
Another consideration, is that the TFS instance we use is shared by all of the Visual Studio team. Because of this, we can’t rely on every checkin to be one of ours, and we also have to expect that some checkin’s to our files should not have all information about them exposed to the world (commit messages about pre-release features, for example). Due to this server, we wanted to make our solution ensures that pushes to the primary IronRuby Git account passed these tests.
Options
We considered quite a few options for this:
- Don’t do it, go with only Git with sync points
- Have one checkin system to checkin to Git and one to checkin to TFS
- Continue with the transform route that the SVN repo used
- Write a
git-tfsadapter similar togit-svn - Use file copying to transfer between TFS and Git, branches to handle merging the files
- Wrap the TFS repository in a Git repository
Don’t do it, go with only Git with sync points
We considered moving the majority of IronRuby’s development off of TFS and only syncing up with the DLR and IronPython at specified intervals. This would have been nice as it would have gotten everyone working out of the same repository and it would have eliminated these entire problems. However, the DLR is evolving too quickly to allow this, and we need to change it too often.
Have one checkin system to checkin to Git and one to checkin to TFS
This would have required massive changes to the checkin system in order to make it understand Git, and it also would have required an internal staging server to allow us to push to. It solved the problem of keeping the source tree passing tests, but it didn’t solve the problem of keeping the two systems in sync. We did consider trying to have the checkin server also push to the external Github account. However, this would have been more changes and would have made an external website able to block our internal systems. Some people also had security concerns with having the CI server automatically pull in external code.
Continue with the transform route that the SVN repo used
When IronRuby used Rubyforge’s SVN repositories, we also used a different source layout. We had scripts that transformed the two repositories to allow syncing these layouts. While this worked, it was error prone. There were heavy maintenance costs to keep the transforms working. There were also numerous cases of overwriting changes on one side or the other of the transform. We decided early on that whatever we did, transforms were out.
Write a git-tfs adapter similar to git-svn
This was tempting, and it is something I had considered since I started at Microsoft (since I love Git, and I’m not as wild about TFS). We chose not to because we didn’t really have the resources to write and maintain it.
Use file copying to transfer between TFS and Git, branches to handle merging the files
The idea with this one was to have 2 repositories: one Git and one TFS. To sync repositories, we would xcopy files from one to the other, then run a git commit or tfpt online to get changes into the repository. Then, to merge them in correctly, we would use a branch to allow the source control system to do the merge. We actually started on this path before we went onto the one we used.
Wrap the TFS repository in a Git repository
Jimmy Schementi is the one that pointed out that there was no reason to have two separate repositories on the system. Since TFS doesn’t store it’s information in it’s enlistment and it doesn’t use extra folders (like SVN), you can just add the .git folder at the root of the “git repository”. Git will take care of itself and track the files, and if you do regular tf get’s, TFS will also stay in good shape. The rest of this series will go into details about this technique, and it will also talk about the scripts we use.
