CODEWITHSUNDEEP
tfs
sambomartin
sambomartin

Reputation: 6823

Team Foundation Server 2010 - To branch or not to branch?

I've currently got a number of Team Projects all happily managed by TFS.

I have one project, a windows app, that is currently in use and before I ported the code base to TFS, we manually used to maintain both the production build and a new development build using scripts to copy/merge the files.

e.g. App1 v1.x - production and App1 v2.0 in development.

Before TFS we manually "merged" to bug fixes from the development build into the production build - so where applicable bug fixes from v1.x were also fixed in v2.

In this particular case v2 is quite different, re-factored ui, etc. The question I have is what is the best way of porting this scenario to TFS.

As I see it I have two options:

  1. Create a new Team Project and continue manually "merging" applicable code files.

  2. Create a brand from the current project v1 and replace / overwrite the project piece by piece in VS so that the source control can manage the changes back to the Main team project. V2 has a few additional class libs too - if that makes a difference.

Upvotes: 1

Views: 1272

Answers (2)

pantelif
pantelif

Reputation: 8544

In short...To branch!

It seems your code between versions is that much similar that you should be fine by simply branching your new release.

In general, changing to a new Team Project makes sense if you have one or more of the following:

  • a totally new bread of requirements and/or different Work Item types
  • completely different technology, in other words you have radically changed the design & merging is more loss than gain
  • need to store docs & other tokens in another SharePoint site
  • different development methodology - process template
  • different teams of people working on both sides, possibly want to restrict users from viewing v1 or v2
  • plan to release both products in completely different release cycles
  • need for totally separated reports

Reading your post I don't recognize the need to go after creating a new Team Project - of course I might be wrong.

In case you decide to go with the branch variant you could be greatly benefited from the impressive Visual Studio TFS Branching Guide 2010, on how to shape the structure of your codebase.

Upvotes: 2

kroonwijk
kroonwijk

Reputation: 8410

Typically, this is the strategy we use to do branching and merging:

  • The project starts. All team members are working on version 1.0 in the single CURRENT branch.
  • Project approaches a milestone or release. Make a branch that will be used to stabilized the code for production in PROD 1.0 branch. Now half of the team stabilizes the product on the branch and half of the team continues doing new (riskful) stuff on the CURRENT branch.
  • PROD 1.0 branch is ready and delivered in production. The branch stays intact to provide maintenance and support on the delivered version. Fixes are made on the PROD 1.0 branch and merged into the CURRENT branch.
  • Project approaches another milestone or release. Make a new branch that will be used to stabilized the code for production in PROD 2.0 branch. The same mechanism is used as described before.

Using this branch-per-release strategy, you always have a branch per shipped and to be maintained version in which fixes can easily be propagated forward and backward between versions and the mainstream CURRENT development line.

With this respect, we use a TFS team project for multiple releases of a certain product. This limits the overhead creating and maintaining the project spaces.

Upvotes: 3

Related Questions