Word on TFS Migration and Synchronization Toolkit

As it has been widely blogged, TFS Migration Toolkit pre-release version become available on 20th of April.

I have promptly downloaded it to have a quick look - after all, migration scenarios is fairly common occurence with TFS implementations, and so far there was not much one could do. But I'd say that the toolkit fell somewhat short of my expectations and here is why:

• It appears to be geared almost entorely to third party developers; if I am going to write commercial solution for Quality Center/TFS sync it certainly makes sense to try and use it. But I fail to see how average customer can benefit from that, or myself as the person implementing TFS - the complexity of writing migration utility appears to be significant


• The example of WSS converter is not something really helpful - of course that's my opinion only. I'd say most people are looking for migration of other version control/bug tracking systems to TFS or synching several TFS boxes rather than WSS solutions. So from my perspective, building an example for WSS that includes all quirks of WSS is not the best candidate for the task. One wants example to be relatively simple, and including WSS does not promote that cause. What about demonstrating power of toolkit on VSS, or ClearCase or BugZilla or Quality Center?


• I am a little unsure of DB usage in the toolkit. So I have to use MS SQL Server 2005; but I remember that license of MS SQL Server 2005 installed for TFS prohibits usage of it for other appplications. Would the toolkit be an exception? Or the license should be acquired? Express edition could be an answer, but certainly not for everyone.

But overall, I am pretty happy about that toolkit being released. At least now there is an alternative to writing things from scratch, and availability of source code will make things easier to understand (ever tried to tweak VSSConverter?).

Increasing source control permissions granularity

It is a known limitation of sorts in TFS version control, that you cannot set the permissions on specific change type - that is you can specify desired permissions on check in, but not on check in of "add" or "delete" changes specifically.

Interesting question from forums dealt with how to implement permissions that will allow folder to support only addition of new files.

So far the best (or at least "cleanest") solution for that appears to be creation of custom check-in policy, that will allow check in of only specific change types. Sample policy was created by Leon Mayne and is available for download here. That policy allows the user to check in only branch/merge related changes.

To extend that approach would be to allow the user configure the permitted change types. As the policy sources are not available as of now, you will probably have to contact Leon for that :)