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!

Solution 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

Solution 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.

Solution 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.

Solution 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 ;)

View more solutions

Comments

[Daniel]

Here is someone else with the same problem: social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thr‌​ead/…

[Daniel]

The answer to this question seems to be subjective. The Microsoft TFS Ranger team have not provided nearly enough information or explanation on this topic. It would be hard for me to award the bounty let alone choosing the "correct" answer so I'll end up doing so based solely on the most up-votes. It would seem both provided solutions would work out fine and the only reason not to use a baseless-merge is only because MS says it's not proper... the reasoning behind which seems to be left unknown.

[Daniel]

This is definitely a possibility. However, the main drawback here is Product1 and Product2 can no longer maintain their own versions of Core. Any build out of Core must be compatible with each project which has a file reference to it. We only have 3-4 team projects so this might be manageable, though those team projects have solution projects in the 12-16 range which might have to reference Core. What is your view on using file references vs baseless merge? Thanks again.

[Daniel]

Would you be able to comment on any kind of foreseeable roadblocks that might arise from doing this? Why does Microsoft tout using baseless merges as last resort / "you shouldn't need this" feature.

[Sunil Agarwal]

Baseless merge is i would say good feature. It's one of the feature we are using against the fundamentals. It's unique command which allows us to merge across branches between whom the relationship doesn't exists. I used baseless merge for my company around 6 months back and we haven't faced any problem yet. It's a boon that we can create relationship between the branches even if there does not exists any relationship. I would recommend you to go forward with baseless merge.

[James Reed]

I guess I'm againt baseless merges in principle, MS recommend against it and I figure they know what they're doing :-) I've used them in the past but only as a last resort. I know that MS have improved them in TFS 2010 sp1 I guess the one thing I dont understand is why a baseless merge works when branching from "core" doesn't? When you do a baseless merge it sets up the merge relationship i.e. Subsiquent merges are not baseless, so the end result would be the same

[Daniel]

Much thanks for your input James, this information will surely be useful in deciding which path to take.

[Daniel]

Thanks for your input Sunil. Myself and the project manager will most likely test out the baseless feature and come to a decision.

[stbear]

Okay, instead of deleting folder, you can convert branch back to folder, but this option doesn't appear for me.

[Brent Newbury]

I know this is old, but you need to select the branch in Source Control Explorer then click File (from the main menu) -> Source Control -> Branching and Merging -> Convert to Folder. This option isn't available in the context menu.

[niaher]

In my team we package our common functionality into NuGet packages. We found it to work very well. Treating your own common libraries as 3rd party dependencies forces you to write more reusable code ;)

[Kamyar]

Using Nuget to manage common code worked very well for us too.