Move your TFS stuff around - or get ready for that!

Just wanted to share a little bit of information - there was a release of a pre-release version of TFS to TFS migration tool on CodePlex. Countless were days of waiting for this tool, and here it has arrived (albeit in pre-release version).

I have yet to test it myself, but it appears that one should be able at least move the version control artifacts and work items between different servers.

As it is pre-release, it can probably get better, so I urge you to have a look and let the team know your thoughts.

Further details can be found at Ed Hintz blog.

Orcas Beta 2 VPC expires soon!

It turned out that Orcas VPCs with Beta 2 will expire on November 1st, 2007. So if you have some data inside, get prepared (apparently it is Windows Server 2003 OS that expires).

See Jeff Beehler's blog post for more info.

Automatic shelving, anyone? No, thanks...

As I am catching up with the blog reading (still have some thousand posts to browse through in my blog reader), I came across interesting post by Grant Holliday.

In a nutshell, there is a new project at CodePlex by William Bartholomew, called QuickShelve, a little utility application that may be used to set up automatic shelving on your machine. Initially, I was pretty excited about it - I am a soldier in "small-free-app-save-big-buck" army myself. But then I thought better of it, and become doubtful that auto shelving is (will be) universally needed, and here is why:

• You need to set up the app on your local machine, since this will only work when agent is running locally. Ah, I wish it could be set up at server...


• When one shelves some changes, it is usually files at certain stage of development ("wow, it works now", "hell, it ceased to work", "i am afraid to change this" etc). Auto shelving, on the other hand, will shelve at some point in time and it wont be easy to identify what exactly is inside


• And lastly - people should check in often. Admin (or team lead) can and should enforce that policy, and may be even monitor the shelving so that no one is tempted use shelvesets as substitutes for checked in changesets. And anything that takes you away from that "daily check in is a must" is a devil's work.

So overall while auto shelving in its current form might be a good way to prevent force major circumctances (hard drive crash etc.), I will wait until it can be set up and administered at server level. That would be a nice feature (Rosario people, are you listening?).

Musings on immigration

I am back after long hiatus and this time I'd like to talk about immigration. Just joshing - about migration really (though immigration is a hot topick too :).
I do hope that many shops working with Visual Studio that still do not have TFS in house are considering evaluating/purchasing it. And even if the question of featureset is satsifactory, the issue of migration is bound to arise.

Actually, first question usually is - do we migrate the history and legacy code, retaining the structure, including the artifacts from bug tracking system or should we start with clean slate green field repository?

And at that stage I think some facts and possibilities get overlooked.

History
When talking of history of all changes performed on the certain codebase for whatever number of years it appears people tend to hugely exaggerate its importance. Try to ask average developer - how often do you look up the history revisions? And how often those revisions are truly historical (not the one before latest)? Chances are (if the guy is not responsible for maintenance of legacy code) that the usage is fairly occasional.
Now, let's suppose that history is not migrated, but that previous repository is readily available for whoever needs that data. Would that not be a feasible solution for occasional usage?

Legacy code
Do you want to have all code in the same repository? On impulse, everyone answers yes. But do you really? If there is virtually no maintenance, and putting the code in new repository means that defect fix procedure, build scripts etc. needs to be updated, it might well be time consuming. So would it be better to have all code ever developed in one new repository? Certainly so. But would it be easier to leave maintenance only code in old repository? Probably yes.

Bug tracking
With the great number of bug tracking systems available (and many of them developed in house) question of migration may be very well dependent on the person performing it. But even with such person available, the same question is relevant as with history - are all those closed defects absolutely required? And do we need those 200 fields that anybody hardly ever use?

So by now I think you catch my direction. While migration of all data from one system to another is the best solution, it is rarely available - and that due to multiple reasons. And in my personal opinion (leaving internal company politics aside) some sacrifices can be made and even may be beneficial to the whole process. Just imagine your source code repository without all legacy crap lying around, restructured logically and not forest of folders that are there due to "historical reasons".

Of course the situation I describe is simplified a lot. And it is apparent that in large organization there will be the need to have both history and legacy code transferred to the new system. But instead of trying to take and transfer everything as is, it might be better to consider an alternative. To me the alternative is this - having old system repository online and accessible (perhaps read-only) after new system is introduced, and starting new repository from the ground up. Or at least consider that for some projects.

And that no migration/limited migration scenario may be especially relevant in case where there is no bridge between source/target systems. For example, how do you migrate from MKS to Team Foundation?

Overall, I do not advocate the "throw the old embrace the new" approach. But I felt in several cases (where people passionately demanded revisions history for five years in new system without ever using it in the old one etc) that alternative should be at least examined. And sometimes doing no migration can be actually be for the better! Dont you think so?