TFS 2010 Branch Across Team Projects - Best Practices

For achieving what you want, you need to first convert all branches under root to folder and then you will be able to convert the root to folder.

We had were stuck with merging under different branch and then we went for baseless merge. It took sometime to figure out how it works but then we were successful in doing merge accross branch and then creating the relationship between them.

tf merge /baseless "D:\TFS2010\Root\ServicePack" "D:\TFS2010\Root\MainLine" /recursive

Once you have done baseless merge, you need to check-in all the files. Still you will find the relationship between the branches is not created.

For this click on ServicePack branch(as per my example) and then from file menu click Source Control -> Branching and Merging -> Reparent. There you will have the option of re-parenting. Once done, hence forth whenever you want to merge across these branches you will be able to do like a normal merge across branches.

TFS 2010 Branching Revisited:

I would like to offer a mode of confidence for the TFS 2010 baseless merge feature as a way to resolve this issue. I highly recommend picking up the Wrox book "Professional Team Foundation Server 2010".

In it, it describes this problem in depth and whilst it doesn't advocate the use of baseless merges, it sheds light on how to use them in scenarios like this.

We have been using them since this question was first resolved back in April and have yet to encounter a situation where the baseless merge present a problem. I wanted to post an image detailing our branching setup as recommended by the book and the ALM Ranger Team.

I'll throw an option in to the ring, it may or may not not be useful to you. If it's any consolation I've been pondering over this one for a while now and haven't been able to come up with a completely satisfactory solution. It's a really good question and I'd be very interested in seeing how others have solved this problem.

I know it's considered a good idea to build from source wherever possible but I'm not a fan of branching between Team Projects. If you have a some common code and it needs to be branched between 2 or 3 other Team Projects then the branching is manageable but if you have 20 or 30 (or 100) Team Projects then managing the merges becomes a headache. There can be other issues if the developers working in the consuming Team Projects don't have the same permissions in the "master" such as not being able to see history etc. Of course if you have code that needs to be shared between Team Projects in different Project Collections then you can't branch anyway.

So with that in mind I would suggest that you treat the common code in the same way you might treat a 3rd party library and use binary references. Once you get in to that mindset a number of options are available to you. (here are a few but there are probably more)

1. You could have the build for your common code copy the binaries to a drop location, alongside a merge module for packaging (if you use MSI). You then create a binary reference to the drop location and get whatever you use for packaging to import the merge module. In this scenario you need to make sure that the drop location is stable (and preferably read only to most of the devs to prevent tampering)
2. Similar to option 1 but use a tool like NuGet to manage your references, this will automate the process of referencing new versions of the binaries.
3. You could just check in the binaries to $/Product1/branch/lib/common folder in your branch and reference them using a relative path

As I said, I'm very interested in hearing how other SOers have solved the shared code problem using TFS.

EDIT: After 8 years of thinking about this, Nuget packages are the way forward here. I've left the rest of the answer in place as it still gets views and up-votes. Building dependencies in to packages and storing them in a binary repository (nuget / Nexus / Artifactory / Azure Artifacts etc.) is pretty much the standard way of solving this problem