For the past few years, I’ve been using Team Foundation Server to address the source control needs of my hobby projects. Soon I’ll have to leave that TFS behind, so naturally I’ve been looking at ways to get my source code out. Getting only the tip of the iceberg is trivially easy of course: get latest version, unbind from source control and you’re done. But I’d really like to get out the history as well. I’ve evaluated several options.
TFS Integration Tools
First stop on the road were the TFS Integration Tools. The TFS Integration Tools are a fairly mature set of tools for migrating from one source control system (including, but not limited to, TFS) to another TFS server. I set up a virtual machine with TFS Workgroup Edition, Team Explorer for both TFS 2008 and 2010. I was all set to go but then I ran into a critical problem: my VM is not in the domain of the old TFS server, and thus I don’t have access to the old TFS from my VM – even though the TFS Integration Tools GUI offers the “connect as a different user” functionality.
I decided to give up on the TFS Integration Tools, since I wasn’t convinced about wanting to store my source in yet another TFS.
Git-TFS
Second stop on the road was the Git-TFS bridge. It quickly turned out that this is really only a bridge: it’s designed for developers who don’t want the heavy-weight TFS source control interfering with their daily work but who will eventually check their stuff in into TFS.
SvnBridge
SvnBridge is another bridge, this time for using TortoiseSVN with TFS. My idea was to use this bridge in connection with a Git-Svn bridge and export everything into a Git repository. I abandoned that idea as well since I don’t feel comfortable using Git (yet).
We don’t need no Source Control …
I finally hit paydirt when the umpteenth Google query came up with Migrating from TFS to SVN. That article describes a way of extracting older versions from TFS by date.
The author (Joel Potischman) goes on to describe how to check in those versions into SVN. I decided I did not want to use SVN either – after all, I just spent several hours getting my code out of TFS, so I didn’t want to put it into another server system that I don’t know too well.
In addition – being the pedantic bugger that I am – I didn’t want to extract my code by date (as in the article), but by changeset. That turned out to be rather easy, and I changed Joel’s TFSGet script as follows:
mkdir source
cd source
"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\TF.exe" get "*.*" /all /version:C%1 /recursive /overwrite
cd ..
rename source %1
You use this script by calling it with the number of the changeset.
Changesets, changesets, changesets
Now all I needed was a list of all changesets in my TFS project to automate calling TFSGet – I didn’t feel like calling it manually about 1000 times.
First idea: get the list of changesets using tf.exe. I didn’t find out how to do that, and neither did our local TFS expert.
Second idea: use the TFS object model. I didn’t find an immediately self-evident way of retrieving changesets from there either.
Third idea: Excel to the rescue. It turns out that getting the numbers of the changesets is trivially easy, in a banging-your-head-on-the-desk sort of way: Stack Overflow has the scope in TFS query (in Visual Studio) to get all check-ins.
So armed with all that knowledge and a bag full of glue scripts I set to work. I left the script running overnight and it was busy extracting the last couple of changesets when I came back to my pc in the morning. Hooray!