Effective Branching and Merging in TFS 2010

07 September 2010 | Eric Swanson | Development, Microsoft, web development | Tags: , , , , , , ,

Many people still struggle with effective branching and merging in TFS; either in understanding the concepts or applying them. I have attempted to address this through a demo using TFS 2010 and Microsoft’s TFS Guidance from the Patterns & Practices and “ALM Rangers” teams.

Microsoft also released the ability to customize the TFS process template guidance on MSDN. See the following resources:

For a demo of how or even why you might do this, see Allen’s post on customizing the process guidance using WebMatrix.

3 Responses to “Effective Branching and Merging in TFS 2010”

  • 1 Peter Larsson Says:
    September 20th, 2010 at: 12:10 am

    Thanks you for a really good and informative video. I have one question though, how would I best implement TFS in a code structure where we have the same code base for different applications.

    For example, we have three applications that use the same DAL, and different programmers in the respective applications. I have not really found a solution for this, what would you recommend?

    Best regards,
    Peter Larsson!

  • 2 Eric Swanson Says:
    September 20th, 2010 at: 7:36 am

    Great question Peter. Think about your common project(s) as an application. A team develops a reusable API for others. This may be the same team or a different team that is working on the other applications.

    You would create a seperate project for this common project and provide releases that support the other applications. It is up to the application teams to decide when they pull a release from the common project based on the application’s release cycle. So, the application team may decide to pull the most recent “releases” update from “Common Project” into my application’s “lib” directory, but I may also decide to pull an alpha or beta release at the application team’s discretion.

    *Important Note: You will want something more specific than “Common”, to enable your team to grow and to separate additional common projects when needed. Depending on team size, hosting a number of sub-projects under main/ may be perfectly acceptable.

    For TFS Project Structure, you have something like:

    Common Project/
  dev/
    main/
  main/
  releases/
    v1/
    v2/
    v3/
App1 Project/
  dev/
    main/
  main/
  releases/
    v1/
    v1 sp1/
App2 Project/
  dev/
    main/
  main/
  releases/
    v1/
    v2/


    For local directory structure (*assumes the contents of “dev/main/” is mapped to the local machine), you might have:

    
code/
  common/
    lib/
    src/
    tests/
  app1/
    lib/
      common/
    src/
      Web.Services/
      WPF/
    tests/
      Web.Services.UnitTests/
      WPF.SystemTests/
      WPF.UnitTests/
  app2/
    lib/
      common/
    src/
      Web.MVC/
      Web.Silverlight/
    tests/
      Web.MVC.SystemTests/
      Web.MVC.UnitTests/
      Web.Silverlight.UnitTests/
  • 3 Michael Konstate Says:
    November 15th, 2010 at: 6:04 pm

    Hi Eric,

    nice video!
    Was very useful for me.

    Greetz,
    Michael

Leave a Reply