Recreate branching structure in TFS source control when only latest files are available

Question

We migrated from a different source control system. The latest files from each branch were checked in to folders in TFS 2010 source control, and we used the "convert to branch" command on each top-level branch folder. Since the initial checkins, work has been done on the trunk and the branches.

However, we can't do merges from the GUI because TFS does not understand the relationships between the branches. The "reparent" command does not offer any options. Is there a way to use tf merge /baseless /discard /recursive to set up the relationships? Will this cause problems since there have been checkins after the initial ones?

Answer 1

I've just spent the last 6 months migrating 100 or so VSS repositories in to TFS so I feel your pain! I've only done this in TFS 2008 but there is no reason why it shouldn't work in 2010.

I would treat a baseless merge as a last resort as you'll be stuck doing merges from the command line.

The trick is to establish the relationship between the branches before you import your code.

(I'll use a simple single dev branch as an example but you should be able to use the same theory regardless of the number of branches)

1. Create a new team project, create your "trunk" then branch to "dev". You should now have two empty branches.

2. Import your code in to "trunk" and "dev".

3. Merge from "trunk" to "dev", you will almost certainly have lots of conflicts, TFS should be clever enough to ignore files and folders that are the same, but not always. You will need to decide which of the conflicting files you want to keep (usually the ones in the "dev" branch but you probably want to have someone who understands the code near at hand to make the decision)

Now you should have 2 branches full of code that have a relationship.

If you have multiple "dev" branches then I think you should always merge from "trunk" to "dev" first, this sets up the relationship and gives you the option of keeping the version of the code in "dev" as this is probably more recent that the version in "trunk"

In your specific case I would follow the above but instead of importing your files (step 2) from the file system, you could branch the code from your "old" team project in to the new one i.e.

branch $/oldTeamProject/Devbranch in to $/NewTeamProject/DevBranch and $/oldTeamProject/Trunk in to $/NewTeamProject/Trunk

then merge $/NewTeamProject/Trunk in to $/NewTeamProject/DevBranch

I've done this a couple of times in TFS 2008 and it works like a charm (except the pain of doing the initial conflict resolution). Having said that I would recommend doing a "test" migration, just to make sure you've covered all of the angles. If this works ok then you can keep the result, if not you should have learnt some lessons for the real migration :-)

If you've renamed any files or folders then TFS won't know to establish the relationship and you'll get duplication in your "dev" branch after the merge. You'll have the same issue if you do a baseless merge at the folder level. There isn't an easy way around this I'm afraid. you just need to keep an eye out for anything that look slike it's been renamed and manually resolve them after the merge.