Merging and branching shared code between projects in TFS

Question

I'm currently in charge of migrating our asp.net applications from source safe to TFS. We have three or four very similar apps (let us say e-commerce) that currently share a core library (services, business logic, entities, data access etc).

The applications are similar but not identical so one app might get a feature set the others won't get etc.

I want to stop the sharing of code and instead set up branches (if that fits) so if I change something in Application A:s core library I will need to merge the changes with the other branches instead of them getting the changes automatically. This to avoid surprises when you update from your trunk and suddenly the core has changed for another project and this project breaks in some way.

Any suggestions on how I should set this up in TFS? Should I have a "main" Core that is not directly used in any project that is the parent of all the other cores so I can push changes up to that one from one core and then distribute it to the other cores? Does that make sense and would it be easy to set up in TFS?

Answer 1

Edit:

After looking at your comment, I'd suggest you'd read up on Feature branches on the CodePlex website.

Scenario 4 – Branch for Feature
In this scenario, you create a development branch, perform work in that branch, and then merge your work back into your main source tree. You organize your development branches based on product features. The following is a physical view showing branching for feature development:

My Team Project

      Development -> Isolated development branch container  
        Feature A -> Feature branch  
           Source  
        Feature B -> Feature branch  
          Source  
        Feature C -> Feature branch  
          Source  
        Main      -> Main Integration branch
          Source

We are moving from SS to TFS in the near future too.
As I see it, we are going to keep our SS repository online and start fresh over in TFS. Our framework probably will get its own project in TFS. Project specific shared units will need to get merged from time to time.

---

The way you structure your repository depends on your specific situation. Every branch scenario has its specific advantages and drawbacks.

• How many projects
• How many developers
• Are the developers dedicated
• Do you need concurrent hot fixes
• Do you need service packs

Take a look at the codeplex branching guide for all the information you need to make an informed decision about your TFS structure. Print out the cheat sheets and pin them to your wall for quick reference.

Before executing on your branch plan, pay attention to this cautionary message - every branch you create does have a cost so make sure you get some value from it. The mechanics of branching in TFS are simplified to a single right click branch command. However, the total cost of branching is paid by reduced code velocity to main, merge conflicts and additional testing can be expensive.

Answer 2

I am assuming you have already investigated whether you truly need to make your "copies" seperate team projects. Remember the TFS concept of a "Team Project" is a VERY LARGE high level container. It is not the same thing as what most IT shops consider a "Project". Think of "Microsoft Vista" or "Office 2007" as a project, not, say "A new release of Company XYZ's Accounts Receivable System" as a project in the Team Project sense.

I have a client that decided on one single Team Project for TFS. There is nothing wrong with this - and it is truly the best scenario in many circumstances.

If you truly need a very strong isolation between your copies of the application (perhaps they are seperate clients and you need very strong security seperation) and must have seperate team projects.

That said - you still - as you've stated need to share code between instances of your application. The first thing I would strongly recommend is to get away from "Cut and Paste" sharing. I would truly try to isolate the shared code into a seperate Solution and generate binaries for that (perhaps you've already done this!)

This is covered in the Codeplex TFS: http://tfsguide.codeplex.com/

Another approach I've done for several clients - is to have a Team Project that contains the shared code. The "Build" creates the binaries for the shared code - and the "Deploy" simply copies those to a "known location" (ie UNC share on the build machine)

For the applications that are "Consumers" of the "Framework" we simply used the "AdditionalReferencesPath" Item group to include the location of that known location.

Furthermore - this tool: http://tfsdepreplicator.codeplex.com/ can be helpful. This would allow you to have builds automatically triggered for your "Consumer" Projects whenever the "Framework" solution is built.