Geek Answers Handbook

TFS Branch Recommendation

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

I have 4 applications that use the Framework, 1 website, 1 console application and 3 other types of applications.

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

I have it all in one Team Project with each build / application in its own folder.

I want to use the branch function for each of the applications sharing the Framework assembly, but I don’t know what is the best way to fork the application with the Framework?

Any suggestions?

I know how branching and merging work, but all the examples demonstrate the forking of everything contained in 1 folder.

+7
source share
3 answers

In light of the image representing your version control directory, I will make the following assumption:

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

First you need to create the Main folder in $/TeamProject (this will be your main - aka trunk - branch) and move all your top-level folders to it.

So 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 select "Convert to Branch". Now TFS will allow you to separate $/TeamProject/Main to $/TeamProject/ConsoleV2 (for example) and work with functions for the V2 console. You can change the Console application and Framework, if necessary, in this thread. When this work is completed, you can invert the integration (merge) of the changes back to Main .

Do not forget to continue switching integration (merging) from Main into your function branch and resolve any conflicts in order to synchronize code bases.

Using this approach, you can modify any part of your products in one atomic test, for example, you change the API on your platform by adding a new required parameter to the method, you can change it in all your applications at the same time, and when you combine RI in Main , everything will be updated.

+7
source

Your main question, as I understand it, is "What is the best branching structure related to my Framework dependent applications?" If you always build and release them together, it’s easier and cheaper to fork them all together, like 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 the changes to the Framework. It is generally recommended that you control access to registration only to those who need it for common projects such as the Framework.

If the latter case is true, then I think your current graphics do a great job of this, 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 linking; this will simplify your workspace mappings:

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

If you want to have branching and merging for individual projects, the only way to achieve this in TFS is to create a separate TFS project for each of the projects in your solution. Hope this makes sense. Once you do this, you can list the code from each project in your working directory.

We recently migrated our code from VSS to TFS. At that time, we had to decide to put all the code in one TFS project or break it up. So, we have a website, a business library (which is used by the website and other applications), a data layer. We have created a separate TFS project for the library, website and data-level projects. Each project would have a trunk branch. All who need the latter would separate their own copy from the body and combine there.

Hope this helps.

-2
source

More articles: