From SVN to TFS: The Good, The Bad and The Ugly

For my recent MSDN TechTalk I did some research how to migrate a source control repository from SVN to TFS. While I am not advocating this migration, here are the options:

The Good:

Currently you have a choice of three tools:

svn2tfs:
svn2tfs is a simple tool written in VB.NET. You need to have SVN installed in order for this tool to work. It basically replays every revision from SVN as changeset into TFS.

TFS Integration Platform:
The TFS Integration Platform is the Swiss army knife for many possibilities to get data in and out of TFS. The TFS integration platform is available as supported Microsoft product on Visual Studio Code Gallery and as bleeding-edge release on Codeplex. The SVN adapter is currently only part of the codeplex release.

Timely Migration:
Timely Migration is a commercial tool. There are different modules for different source version control systems. To migrate from SVN to TFS the SVNToTFS module is needed. It costs $1995. Trial versions can be requested, but they do not migrate the content of the files.

svn2tfs	Integration Platform	Timely Migration
open source	open source, from Microsoft	commercial, $1995
simple and easy to use	many features, complex, complicated	powerful features, easy to use
enough documentation	sparse documentation	good documentaion
SVN tags can be migrated as branches	SVN tags are migrated as branches	SVN tags are migrated to TFS labels
user-mapping is enforced	user-mapping is possible but not enforced	user-mapping is enforced and comfortable
migration is aborted in case of an error	some errors can be manually resolved and migration can be then be resumed	migration gets resumed when restarting after error resolution

With each tool I was able to successfully migrate an example project from a local SVN repository.

The Bad:

svn2tfs: I was not able to migrate SVN repositories from Google Code. The tool systematically failed, because the initial repository revision for the project layout (dirs for trunk, tags and labels) has not author. The tool can not deal with that. On the positive side was, that the source code of the tool is very simple so that I was quickly able to create a patch, that fixed this problem. On the negative side was, that there was no reaction on the patch I submitted. The project seem pretty dead.

TFS Integration Platform: It seems not possible to do an aynonymous login to SVN. If you do not provide valid user/password, the migration fails with an ugly “NullReferenceException”. The documentation for the SVN adapter is sparse. For instance there was no documentation at all how to map svn users to TFS users. fortunately (after some nudging from my contact at Microsoft) my question in the forum was answered. Some days later even a blog post about the topic was published. Another shortcoming is, that the mapping from svn users to TFS users is not enforced. If no mapping is specified, each svn user is silently mapped to the user that is running the migration tool. There is no support in checking if all users from svn are mapped to TFS users.

Timely Migration: The only negative thing is the price since you probably need the tool only once.

The Ugly:

With none of the tools I was able to migrate the Nerd Dinner repository from Codeplex. Each tool either reported an error or froze indefinitely.

If you like this, follow me on twitter...

Is there any hope for other DVCS in the Git imperium?

As we are entering the era of language wars on the JVM there is another war looming on the horizon...

This new war is coming out of the realm of distributed version control systems:

Git seems to have a nearly undisputed imperium in this realm and recently has squished its known competitors:

• GitHub is THE repository for thriving open source projects. Recently I find me browsing on GitHub much more often than on Google Code or CodePlex ... while BitBucket as the main Mercurial contener only plays a marginal role in my experience.
• Google Code, who was favoring SVN and Mercurial for some time, recently added Git support ...
• A lot of the new hot-and-hyped cloud based PaaS are using Git as their tool of choice for deployment: Heroku, JBoss OpenShift, AppHarbor ...

Despite the seemingly striking dominance of Git, there are still brave contenders sprouting out of the dvcs land:

• Veracity by sourcegear
• Plastic SCM
• and older, yet still thriving: Mercurial, Bazaar, Fossil ...

All of them featuring some unique features (although features I am not always sure I would like to see coupled to a source control system ...) and most of them somehow promising more simplicity compared to Git.

I wonder if they have any chance against the massive momentum of Git and its ecosystem ...

If you like this, follow me on twitter...

Agile in the real world (construction analogy again)

Prediction is difficult, especially of the future.

–Niels Bohr

There is a common claim that we should learn more from classical engineering disciplines like civil engineering. According to that claim the IT industry would be a better place if we would adopt best practices from the latter.
But when we look closer, then we can see similar problems in those real engineering disciplines ... this picture is a poignant example of that.

If you like this, follow me on twitter...

Tidbit: Big Data

The amounts of data that Twitter handles is astonishing:

• 12 TB per day (= 4 PB per year)
  • ... this equals 17'000 CDs per day
  • ... this equals 9 mio floppy disks per day ( = 26.5 miles high)


• And the amount is doubling multiple times a year.

... this is according to the presentation NoSQL at Twitter from October 2010, so today the pile of floppy disks would probably already be 50 miles high...

 

Test Driven: It is the mindset not the tool!

It is amazing to realize how old the notion of Test Driven Development (TDD) really is. Here are two quotes, that are older than I am, describing the ideas behind TDD :

Report of the NATO Software Engineering Conference 1968:

A software system can best be designed if the testing is interlaced with the designing instead of being used after the design. Through successive repetitions of this process of interlaced testing and design the model ultimately becomes the software system itself. I think that it is the key of the approach that has been suggested, that there is no such question as testing things after the fact with simulation models, but that in effect the testing and the replacement of simulations with modules that are deeper and more detailed goes on with the simulation model controlling, as it were, the place and order in which these things are done.

 

The humble Programmer, Edsger W. Dijkstra 1972:

But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer's burden. On the contrary: the programmer should let correctness proof and program grow hand in hand. [...] If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof's requirements, then these correctness concerns turn out to be a very effective heuristic guidance. By definition this approach is only applicable when we restrict ourselves to intellectually manageable programs, but it provides us with effective means for finding a satisfactory one among these.

 

Today we mostly associate TDD with automated unit-tests and the family of xUnit Frameworks. We associate TDD with writing code.

Yet TDD today is far from being mainstream in my experience. And even teams that decided to adopt TDD are constantly struggling with implementing it in reality.

The participants of the NATO Software Engineering Conference from 1968 probably had quite a different notion of implementing TDD than we have today. Their implementation of TDD was probably far away from the automated unit-tests we strive for today. Yet they had the same mindset that we pursue today.

When Dijkstra was already preaching TDD, the xUnit-Frameworks were not to be born for another 26 years.

In the last few years I have come to the conclusion, that the most important aspect of TDD is the mindset that comes along with TDD.

This mindset is much more valuable than any tool, technology or methodology that is commonly associated with TDD today.

With the right mindset we can practice TDD even in environments where we can't write unit-tests (Lo and behold, I am even thinking of SharePoint Development). TDD does not have to be realized by writing code. Nor is writing unit-test always the best way to implement TDD.

With the right mindset we can even practice TDD with manual testing!

The actual implementation of the test is rather a detail of TDD. Much more important is the mindset of practicing baby steps, the mindset of gaining insights and evolving through rapid feedback, the mindset of leveraging trial & error as a methodology, where errors are not failures but valuable insights that guide the evolution of the project.

This mindset is the reason why children in kindergarden are scoring better than MBA graduates in the Marshmallow Challenge:

And it is our God Complex that prevents us from keeping that mindset.

But when we embrace this mindset, we realize that it is applicable in many other areas than writing software. It is applicable to any goals that we try to accomplish in unordered domains, where the result of an action is literally unknowable. Internet startups are the perfect example for this: In a lot of cases it is he best option to ship something, and then respond to the market reaction. The crucial requirement for this fast-feedback cycle is to establish a "safe-fail" environment, where we can embrace failure and leverage failures to guide us to success.

Steve Freeman writes about Test-Driven Development and Embracing Failure and Obie Fernandez writes about Testing against business metrics that has nothing to do with code.

If you like this, follow me on twitter...

Quotes of the Week: From NDC 2011

My favorite quotes from NDC 2011:

There is no measurement for technical dept. But the closest measurement is lines of code.

- James Shore

 

It is all very complicated but not magical!

- John Skeet

Their "one-click-deploy" involved a telephone call, copy-paste sql-scripts and chanting & praying.

- Gojko Adzic

 

Software development is about creating something specific not something generic.
(Else you can send the customer a virtual machine, that´s generic.)

- Kevlin Henney

 

Take your last shipping project: Probably you could power-type all the code in one day … How do we spend our time?

- Douglas Crockford

 

About productivity: How good are you in thinking while typing?

- Kevlin Henney

 

If you have git, you have source control - if you have TFS, you have my condolences.

- Hadi Hariri

 

If you like this, follow me on twitter ...