TFS VSS Mirgation and Team Build Config

VSS Migration

One VSS to TFS migration is done... Again, it’s best to follow the doc’s.

It’s a manual, command-line driven process, but it’s not that hard. Create a folder, create a XML settings file (cutting-n-pasting from the doc’s... see I told you following the doc’s was a good thing), fire up the VSSConverter utility to analyze the VSS DB, tweak the settings file, run VSSConverter again to migrate...

All in all, pretty easy and painless.

For my one small test VB8 project at least. ;)

The one thing I did cowboy was to not follow the instructions on manually backing up the VSS DB and then using that backup. Our VSS hosts years of projects and releases. Across a couple product lines... Yeah, we’re pushing it close (to the VSS cliff edge). For example, my product line alone has a 900MB archive.

So since our VSS DB has such an accumulation of projects, I decided I was going to take another approach. I archived my test project, using the VSS Admin tool, copied that archive local, restored it to a local VSS hive and then migrated that.

Yeah, I know that’s not perfect (restoring to a different location can break links, etc), but in my case, I’ve kept my product line fairly isolated from other projects, so it worked like a charm.

Also it lets me analyze/repair a much smaller VSS hive, isolates my work from others using the production hive, etc.

This procedure worked great for my one project... So now it’s time to try it with my entire product line’s VSS hive. I’m copying down the archive and will be prep’ing that for migration. This will be interesting in that it contains VB6, VB7.1 and VB8 projects...

One other thing... In creating a local hive, I can clean it up, nuke old crap (and I still have the source archive if I ever need that crud...). No need to deal with stuff that’s just not valid anymore. This is a good time to clean house...

Team Build

Since I now have a VB8 project under TFS version control, it was a good time to knock out my Team Build to-do item.

Earlier, I was a little confused about Team Build. I thought it was supposed to go on the TFS server and that I’d have to figure out how to put it on another box. Nope, that’s not how it goes. MS was much smarter than that.

Team Build is MEANT to be run on another workstation, or side-by-side on your dev box or both.

Again, read the doc’s. Team Build’s doc’s are a little lighter, but still a good resource. The setup is very easy, as long as you know to run [%TFS CD-ROM%]\build\setup.exe. There’s no menu/auto-run item for installing it.

In any case, I have team build in side-by-side mode on my dev box up and running, with a successful number of Team Builds now under my belt. The next step is to get a stand alone team build machine (the request has already been submitted)...

Some Notes:
A) Watch your path lengths.
When you create a "Build Type" you have to enter the local path that will be used to build the solution(s). This is where the source, once it’s been grabbed from version control will be put, the exe’s built, etc.

Well I like descriptive path names. And hiving my folders. So I created a rather long path for the Build Type.

Add that to the solution paths and I broke 260 characters. Dogh! (Let’s not get me started on how much I hate how the shell and most app’s use the ANSI (ASCII?) File IO API’s when the Unicode API’s will allow paths 32K long...).

So in your Build Types, use short local paths (like C:\TFSBuild\).

B) To edit your Build Type’s, you’re in XML land.

One you create your build with the wizard UI, to edit them, you’ll need to manually check out the .PROJ file from version control and edit XML.

What’s cool is that MS makes that VERY clear in the PROJ file itself. In the comments at the top of the PROJ file are all the instructions you should need as to where to get the file, check it out, edit and check it back in...

C) Team Build is Hacker Friendly

There’s a bunch you can do with Team Build (as it’s based/using MSBuild), but it’s going to take hacking to make it all happen. The wizard to create the Team Build is all the Build Type UI you’re going to get (except for the start build dialog and the results report...)

Meaning to extend your Team Build, you’re hacking the XML in the PROJ file...

What’s nice is that the schema for that is already installed, so you get intellisense when editing it.


That’s enough for today... I think my brain is full ;)

Related Past Post XRef:
TFS - Work Item’s and Customization
TFS Lesson #2 - Listen to my own advice...
TFS SQL Databases Moved... One Tip, Remember the DB Owner
"Moving Your Team Foundation Server Deployment"
My First Soup to Nuts Team Foundation Server Install
TFS Check In Policies, Code to Police Code
"An updated TFS MSSCCI provider is available"
VS6 MSSCCI Provider for TFS
TFS Administration Tool
"Migrating from Visual Source Safe to TFS"
"How many users will your Team Foundation Server support?"
Team Foundation Server 2005 & the "New" MSDN Universal

Technorati Tags: Team Foundation Server, TFS, Visual Studio Team Suite