Branching in TFS - branch whole codebase like in git, or affected sub-project only?

Question

We're updating a large project from VSS to TFS2010, and we need to establish good branching/merging strategies. We are in favour of feature-branches but I have no idea if we should branch only the sub-projects/files affected in each feature (like we would in VSS) or should always branch the whole code-base and rely on lazy copying and good merging (like in git/mercurial).

The guides I've found so far online talk about branching strategies (branch by release, feature, etc) but not about which files/sub-projects you should perform the branch on.

Is there a "right way" to do it? Say we have a setup like this:

Code
|
|- ModuleA
|- ModuleB
|- ModuleC
|- ModuleD

And we have a feature F which impacts ModuleA and ModuleD. Would we be better to branch Code, or ModuleA and ModuleD only?

Answer 1

If your feature is impacting something that is used throughout your codebase, branch your entire codebase. You still want to have CI builds running on your feature branch, and thus you want all of your automated tests to run, same as always.

Even if a feature only affects one small segment of your application, you still want to be able to test the application as a whole to make sure you haven't introduced any breaking changes.

I recommend reading the ALM Rangers' branching/merging guide, which you can download from CodePlex.

Answer 2

I read lot on this subject (Techdays, videos, etc.), on my project apply this strategy, it's recommended as best practise.

The implementation requires performing the following tasks:

1 . Create a truncated development , trunk reads XYZ

Note: developments are not directly on the trunk, but are about a girl called Service Pack branch .

2 . Create from the trunk a new child branch service pack, language 1.YZ

Note: This branch will host the first dedicated development functionality.

Event Project: End of first iteration ( The development team believes that the developments are completed).

3 . Create from Service Pack 1.YZ a new child branch Fix denominated 1.0.Z.

Note: This branch contains all developments dedicated to future bug fixes following the delivery of the target feature.

4 . Create from Fix 1.0.Z. a new child branch Release denominated 1.0.0 .

Note:

• This branch will remain read-only.

• This branch is the only branch deployed in a production environment .

• This branch is a picture of our delivery.

• It allows you to draw different deliveries made .

• It allows to perform operations on the Rollback version if the need arises ( Avoid conflicts file version ) .

Event Project : Delivery of production

1. Deliver Release 1.0.0 branch on the production environment .

6 . Merge Service Pack 1.Y.Z to X.Y.Z trunk

Note : At this point all branches are at the same level of evolution .

Event Project: bug occurs on the Release 1.0.0

7 . The treatment of bugs can be done in two ways as possible :

■ If it is determined that the version is not stable Carry - on patches Fix branch 1.0.Z.

• Create a new branch Release 1.0.1

• Deliver the branch Release 1.0.1

• Merge Fix 1.0.Z to Service Pack 1.Y.Z.

• Merge Service Pack 1.Y.Z. to trunk X.Y.Z.

  Note: You can iterate many times : 1.0,1 , 1.0.2 , 1.0.3 etc. .

■ If it is determined that the version is stable and we decided to fix bugs on a new delivery. - Create from Service Pack 1.Y.Z. Fix a new child branch 1.1.Z

• Make corrections on Fix branch 1.1.Z

• Create from Fix 1.1.Z. a new child branch Release denominated 1.1.0 .

• Deliver the 1.1.0 branch

  Event Project: An important new feature comes

8 . Create from the trunk a new child branch service pack, language 2.YZ

Reproduce the same organization ...

Remark : on my blog i writted post