TFS 2010 Branch Across Team Projects - Best Practices

Question

I'm having issues understanding how to configure TFS according to best practices as provided by the TFS Ranger team. The issue is such:

My company has several products which make use of a shared common code base.

> $/Core
>  -> /Main/Source (Parent Branch)
> 
> $/Product1
>  -> /Main/Source
>  -> /Main/Source/Core/Source (Child Branch from $/Core)
>  -> /Main/Source/...
> 
> $/Product2
>  -> /Main/Source
>  -> /Main/Source/Core/Source (Child Branch from $/Core)
>  -> /Main/Source/...

Therefore we have one team collection and say, three team projects for this example. ($/* is a team project)

Our initial release branching is a bit of a pain. Instead of branching on the /Main to /Releases, or /Main to /Development, we have been branching each project individually. (Not team project ... solution project.)

This is due to the inability to have nested branch roots. (See TFS Errors: TF203028 and TF203071)

According to TFS Ranger Guide and our revised approach to branching releases, hotfixes, developments, we should branch from /Main rather than /Main/Source/Proj1,/Proj2,/Proj3, etc. It's just become a rather large annoyance.

Ideally we would like:

> $/Product1
> -> /Main/ (Branch - Parent)
> -> /Releases
>    -> /1.x
>       /1 Service Pack (Child Branch from $/Product1/Main
>       -> /1.0
>          -> /1.0 Hotfix (Child Branch from $/Product1/Releases/1.x/1 Service Pack)
>          -> /1.0 RTM (Child Branch from $/Product1/Releases/1.x/1.0/1.0 Hotfix - Read Only)
>          -> /1.0.22 RTM (Child Branch from $/Product1/Releases/1.x/1.0/1.0 Hotfix - Read Only)
>       -> /1.5
>          -> /1.5 Hotfix (Child Branch from $/Product1/Releases/1.x/1 Service Pack)
>          -> /1.5 RTM (Child Branch from $/Product1/Releases/1.x/1.5/1.5 Hotfix - Read Only)

Solutions: 1. We can convert each shared branch (ie. $/Core) back to regular folders. This way no folder under /Main is a branch root. We can then perform a baseless merge from $/Product1/Main/Source/Core/Source back to the parent $/Core/Source.

Has anyone any experience with baseless merges. What I've read from Microsoft is that they are exceptions which should not be commonplace. MS states that if you set up your projects properly with TFS, you would never need to perform a baseless merge.

How is this possible when branching across team projects?!? It should be commonplace in any software development house to have shared libraries amongst products.

I'm open to other solutions too.

Thanks!

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

I've been configuring TFS just now and met with the same problem. The point is, there's no need in baseless merge. Workaround:

1. Create parent branch

   $/Core/Main

2. Create child branch

   $/Product1
   -> /Main
   -> /Main/Core
   -> /Main/...

3. Delete child branch folder

   $/Product1/Main/Core

4. Create folder with the SAME name

   $/Product1/Main/Core

5. Convert Product1 folder to branch
   

   $/Product1/Main

Now you can merge changes from $/Core/Main to $/Product1/Main/Core and backwards.
Visualization won't work for Core branch, but it's okay I guess ;)

Answer 5

If you want to share common code then you can try the following solution:

Go to File->Source Control->Add Project from Source Control...

This will pop up a dialog allowing you to add a project from elsewhere in source control.

Once you get into sharing projects like this, it's worthwhile getting a bit robust in your source control structure.

One thing I notice is that if you make changes to the common code then it will not be automatically checked out. So it's kind of similar to referencing the projects difference is that it works in the TFS as well.

Original answer