Reputation: 3523
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.
Upvotes: 7
Views: 2836
Reputation: 954
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
...
Upvotes: 2
Reputation: 52788
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.
Upvotes: 7
Reputation: 2623
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.
Upvotes: -2