Cloning a TFS branch to Git in three simple steps

So it’s pretty straightforward to transfer TFS code, with history, into Git. This post shows a simple way to ‘clone’ TFS into a new Git repo.

1) Install Chocolatey

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString(''))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin

2) Use Chocolatey to install GitTfs. Close Visual Studio first, though.

cinst tfsgit

Then restart the command window.

3) Choose a branch and get cloning;

git tfs clone http://tfsserver:8080/tfs/TfsInstanceName $/TeamProjectName/Path/To/Branch

That should sort you out. 

Creating Node packages in NPM

npm is the package manager for Node.js, the server-side JavaScript thingy. And it’s lovely. On a day-to-day basis, doing C#, I use NuGet in Visual Studio. While NuGet is a welcome addition to Visual Studio, npm seems to make it much easier to create and reuse packages. 

For instance, I’ve just pushed my parsing library, canto34, up to this location on npm, and the process was remarkably easy. The steps are –

1. create a user on the npm website.

2. Link your computer to it with npm command line;

npm adduser


3. Create a single file (package.json) which describes the package, its dependencies, and its location in git

4. Publish the package using npm again;

npm publish

And that’s it — package deployed. 

Now, that’s pretty sweet — anyone in the world can install the package using this command line;

npm install canto34

And get going with the library. But what about me? I want to continue to develop canto34 here on my dev machine, and use it in another project (in my case, a little program called Mettle that’s beginning to take shape.)

So I want to make changes to canto34 as I make changes to Mettle. I don’t want to have upload changes to canto34, and then download them in Mettle. I just want to develop both. 

npm lets you do this by CDing into canto34’s directory and typing

npm link

And then CDing into Mettle’s directory and typing

npm link canto34

Magic! npm ‘installs’ canto34 on my machine using a shortcut to my development copy, so that I now have this structure on my disk;


And I can now develop both projects together.

The thing here isn’t that the command line support is good — on its own, that’s pretty dull. The nice thing is now the npm system seems really well designed to get you sharing code, and doesn’t punish you for doing so. You can share libraries as open source, or use them in proprietary projects, or mix the two together, and it feels like npm is your buddy — a little like, I guess, an author feels about an editor; the technical guy that gets your artistry out to the world. 

All in all, a very good developer experience


Is mercurial dying?

Is it me, or has Mercurial well and truly lost the race against git? 

A couple of things make me think that mercurial is no longer a particularly viable option. Firstly, I’m only really hearing about development on git, and particularly on GitHub. I regularly hear things like “I just pushed TCP support for <package X> to GitHub” but I don’t know that I’ve ever heard a similar “<package X> just got it’s tests fixed on BitBucket.” Maybe this is because I’m looking at a lot of JavaScript projects and not looking at Python projects, but it definitely seems that all the cool kids are on Github. 

Second, I just did a very quick scan for git and mercurial integration for Visual Studio. Microsoft are releasing a git extension in their next service pack (Visual Studio 2012 Update 2). Mercurial integration packages like VisualHG aren’t even compatible with Visual Studio 2012.

The disappointing thing here is that GitHub’s policy on private repos is so much tighter than BitBucket. In BitBucket, I get unlimited free private mercurial and git repos. In GitHub I have to pay to get any. I understand why GitHub needs to charge. Of course I do. It’s just that I’ve been avoiding Github because I have a lot of stuff that’s not fit for public consumption but which I want under source control.

Ah, well. First-world problem.