Invariably, when you work in the ALM field enough, you get your share of source code migration projects. Lately, I’ve had a few of those, and many of them between two separate Team Foundation Server instances. In the world of source code migration, often consultants will look to recommend either tip-only migration or the use of automated tools to essentially play-back all the changesets/checkins from the old system into the new one. The tip-only migration means to get-latest the code from the old, and check that latest version into the new system. Although typically far simpler, this approach of checking in a single latest version does have its complications. Lately, I’ve worked with several clients that have had invested in shelvesets that need to be brought over. In those cases, the teams had access to both the old TFS server and the new one at the same time. I had written up some instructions on how to do this easily for the developers so that they could bring over their own shelvesets at their convenience before the old system was taken down.
This approach is not-automated and requires the users’ participation, but is a decent option for small teams.
What you need is a developer’s local workstation with workspaces mapped to both the old and the new TFS servers.
- Ensure that a local workspace for the old environment is mapped and up to the version of code that your shelveset is based on (often this is “latest”). At this point, TFS believes that the local workstation has the latest version of the code.
- In Windows Explorer, navigate to that location and Delete everything under the workspace mappings to that the folder itself is empty. TFS may detect that as a bunch of deletes, but that’s okay.
- Unshelve the shelveset to be migrated. At this point, the old workspace’s folders should only have the shelveset files in it.
- Paste that set of files into the new workspace in the right place in the folder structure.
- If using VS 2012 or VS 2013, Open up the Pending Changes Window and ensure to promote those changes that should show up now as Pending Changes.
- If your original shelveset included any deletions, the developer will need to go perform those deletions in the new workspace as well.
- Shelve the changes.
At this point, you should have a shelveset mapped to the correct folder path in your new environment ready to be used by the developer.