TFS Branching recommendation

Question

I have a Solution called "Framework" which is a C# assembly for my business logic and data transactions.

I have 4 applications that use Framework, 1 website, 1 Console app and 3 other types of applications.

$/TeamProject
    /Framework
        /Dev
        /Main
        /Release
    /WebApp
        /Dev
        /Main
        /Release
    /WCFApp
        /Dev
        /Main
        /Release

I have all these in one Team Project with each assembly/application under its own folder.

I want to use the branching feature for each of the applications that share the Framework assembly but I don't know what is the best way to branch the Application along with the Framework?

Any suggestions?

I know how Branching and merging works, but all the examples only demonstrate branching everything that is contained in 1 folder.

Shown how my files in source Control currently look – Andy Clark Jun 13 '12 at 21:24 — Andy Clark, Jun 13 '12 at 21:24

score 7 · Accepted Answer · answered Jun 13 '12 at 20:53

7

In light of a picture representing your source control directory, I'll make the following assumption:

$/TeamProject
   /Framework
   /Console
   /Web
   /etc.

What you need to do first is create a Folder called Main in $/TeamProject (this will be your Main - aka trunk - branch) and move all of your top level folders into it.

So then we have:

$/TeamProject
   /Main
     /Framework
     /Console
     /Web
     /etc.

Now you need to convert Main to a branch, you can do this by right clicking on the Main folder and choose "Convert to Branch". TFS will now allow you to branch $/TeamProject/Main to $/TeamProject/ConsoleV2 (for example) and work on features for V2 of the Console. You can modify the Console Application and the Framework if required in this branch. When this work is complete you can Reverse Integrate (merge up) the changes back into Main.

Remember to keep performing Forward Integration merges (merge down) from Main to your feature branch and resolving any conflicts to keep the code bases synchronised.

By taking this approach you can modify any part of any of your products in a single atomic check in, say for example, you change an API on your Framework adding a new mandatory parameter to a method, you can change it in all your apps at the same time, and when you RI merge into Main everything will be updated.

answered Jun 13 '12 at 20:53

DaveShaw

52,123
16
112
141

I am aware of this apprach, the problem with this is if I want to Brach my Console App along with the Framework I have to Branch everything along side it... is this the usual approach? Seems a bit over kill – Andy Clark Jun 13 '12 at 20:55
Where you branch from in the Source Repository won't change the size of the branch it creates. We used this approach to branch several different parts of our application that are version independent so that we can update dependant parts at the same time. You can just ignore the folders you don't work on. – DaveShaw Jun 13 '12 at 20:59
I have added a "visual" of how my source code is currently structured in my team project – Andy Clark Jun 13 '12 at 21:31
2

Daves suggestion is pretty much the standard approach. If you're making changes to framework for your web app, and this is breaking code in your wcf app because the API is changing, you could keep framework where it is and check the stable binaries in to source control. Effectively you are treating framework as a 3rd party library like "enterprise library", where your web app references version 2.0 and your wcf app references 1.2. This all depends on the trade off between fixing breaking changes as they happen, or having stable dependencies. Both approaches have pros and cons – James Reed Jun 13 '12 at 21:46
@DaveShaw I am bashing my head for few days now on how to deal with this, and since there are not whole lot of options, I thought about this as best option especially since I have one big sln that references all projects just to make it easier to fix all places where common code is used but had my doubt like Andy cause it seems like overkill, anyway seeing your rep sure helps to confirm that it is a valid option. Thanks! – formatc May 07 '15 at 12:19
@Unavailable this isn't always the best approach, but it can help keep things simple when you have a small enough code base. Branching is a way to do what you want - figuring out what you want can be the hard part. The ALM Rangers have good PDF's on TFS branching and all the options - http://vsarbranchingguide.codeplex.com/ There are alternatives to this (for example having the Framework as a NuGet package), which I hope to blog about one day. – DaveShaw May 07 '15 at 16:18

score 2 · Answer 2 · answered Jun 14 '12 at 22:37

Your primary question as I understand it is "What is the best branching structure to branch my applications that depend on Framework?" If you always build and version/release them together then it is simpler and less expensive to branch them all together as DaveShaw descibes; however, if each of them is developed by different teams, have different release schedules, have different versions, etc... than you will want to create a MAIN branch under each of them. In this case, it should also be clear who owns changes to Framework. It is usually a good idea to control check-in access to only those who need it for shared projects like Framework.

If the latter case is true, then I think your current graphic handles it nicely, but I would make one change; Keep your Releases at the same level in the hierarchy as the MAIN branch so that the relative path remains the same for making references; this will simplify your workspace mappings:

$/TeamProject
    /Framework
        /Dev
        /Main
        /Release1
        /Release2
        /Release3
        ...
    /WebApp
        /Dev
        /Main
        /Release
            /Release1
            /Release2
            /Release3
            ...
    /WCFApp
    ...

Skadoosh · Answer 3 · 2012-06-13T20:46:08.883

-2

If you want to have branching & merging for individual projects, the only way to achieve that under TFS is to create a separate TFS project for each of the projects in your solution. Hope that makes sense. Once, you do that, then you can branch code out of each project into your working directory.

We migrated our code from VSS into TFS a short while ago. At that time, we had to decide to put all the code into 1 TFS project or break them out. So, we have a website, a business library (which is used by the website & other apps), a data layer. We created a separate TFS project for the library, website, and the data layer projects. Each project would have a trunk branch. Everyone needing the latest would branch their own copy from the trunk and merge back there.

Hope that helps.

edited Jun 13 '12 at 20:46

answered Jun 13 '12 at 20:39

Skadoosh

2,575
8
40
53

So how are you merging each assembly into 1 branch? – Andy Clark Jun 13 '12 at 20:53
Here's the thing. Every developer would have to keep a local solution file. So, if I need the website, library, & data access library, I would get those branches from TFS into the solution on my end and never check in the solution. – Skadoosh Jun 13 '12 at 20:56
Take a look at these: http://stackoverflow.com/questions/400517/tfs-structure-multiple-projects-or-single-project and http://stackoverflow.com/questions/867628/merging-and-branching-shared-code-between-projects-in-tfs – Skadoosh Jun 13 '12 at 20:56
I also found this MSDN article to be helpful: http://msdn.microsoft.com/en-us/magazine/gg598921.aspx – Skadoosh Jun 13 '12 at 20:58
On your second and third comment: Would I branch out the Framework and the App/Website etc separately then combine them in a solution away from source control, then merge them again separately when complete? – Andy Clark Jun 13 '12 at 21:06
If you want to have seperate branches for each component, or group of components you don't need to create a team project for each one. You can create folders at the root of a team project and branch from there. I wouldn't recommend defaulting to this approach though, you should think about your product and its life cycle. If you have a framework that's used by multiple products then that's a candidate for a seperate branching strategy. In that scenario it's best to put the project(s) for the framework in thier own solution and use binary references in your other solutions. – James Reed Jun 13 '12 at 21:35
Also If your developers are having to create their own solutions outside of source control, that suggests your source control / branching strategy is wrong – James Reed Jun 13 '12 at 21:35
-1: bad advice. You seem to have missed the point that a TFS Team Project is nothing like a "project" in VSS. – John Saunders Jun 13 '12 at 22:36

TFS Branching recommendation

3 Answers3