If you have some Visual SourceSafe still lying around your datacentre, here’s how to kill them with no pain
First of all: you’re going to need the VSSConverter, a fantastic tool contained in the Visual Studio installation, under
<drive>:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE
Beware: with Team Foundation Server 2012 there’s going to be a new tool to perform migrations. I’m going to post something on the new tool as soon as I can, but for now this is the only way to migrate it. Moreover, if you won’t have Team Foundation Server 2012, you have not that much possibilities…
I strongly suggest you to copy the VSSConverter and its related files inside a folder, like <drive>:\Migration, in order to keep everything simple.
Then you have to create two XML files: one is for the Analysis, and the other for the Migration. I won’t go into details, everything you need about those files are into the MSDN but…I provide you two samples
here’s one for the Analysis, and here’s the other for the Migration.To analyze the Visual SourceSafe database, use the following command (from an elevated command prompt):
vssconverter.exe analyze analysissettings.xml
It analyzes the Visual SourceSafe database (or part of it), and provides us a report, to understand whether there are errors, and a UserMap.xml file. Inside of it we can find the Visual SourceSafe users to map to the correct Active Directory user in Team Foundation Server.
What does it happen if I don’t map a user (for various reasons)? Well…despite it’s strongly suggested to do so, the difference in behavior is the following:
With:
Changeset 4121 – Committed by DOMAIN\UserWhoDidIt – Comment
Without:
Changeset 4121 – Committed by DOMAIN\MigrationUser – Comment (Committed by UserWhoDidIt)
After finalizing the user mapping, we use the following command to migrate:
vssconverter.exe migrate migrationsettings.xml
And the migration takes place
that’s it!
No comments:
Post a Comment