CODEWITHSUNDEEP
version-controltfsbranchbranching-and-merging
vlfig
vlfig

Reputation: 365

Branch per promotion tradeoffs in TFS

Suppose we have a big TFS 2010 project with three branches: MAIN, TST and PRD.

The strategy is: whenever a Sprint finishes MAIN is copied/merged into TST. Whenever TST is deemed stable it is copied/merged into PRD. Whenever TST or PRD have fixes, they're merged back to MAIN, or MAIN and TST. (Don't ask me why, I can't control this and I don't particularly like it.)

At each promotion step, as I understand, one can either:

  1. delete the target branch and branch again - this entails losing immediate access to that branch's history (it can always be recovered, right?);
  2. merge and resolve with acceptTheirs - this entails loosing changes that may not have been merged back from target to origin.

For the merge-backs, it is important to have ancestry information. With 1. I would expect ancestry information to be kept. With 2. I am unsure.

So, two questions:

  1. Are those two the possible/desirable ways to go about promoting software between branches?
  2. I which cases is ancestry information not kept?

Extra points for any additional tradeoffs that might be relevant for big-size repositories.

Upvotes: 2

Views: 312

Answers (1)

Rolf Huisman
Rolf Huisman

Reputation: 1437

1.Are those two the possible/desirable ways to go about promoting software between branches?

If MAIN has a child branch TST, which has a child branch PRD then without resorting to baseless merges, these are the only merges possible to promote changes between branches.

If this is a desirable branching strategy, depends on many factors like how many parallel releases are put out and team sizes. A good reference guide on this is the branching guidance of the TFS Rangers http://vsarbranchingguide.codeplex.com/ The version you are seem to be using is a variation of the basic dual branch plan (what you call main, they call dev and your production branches aren't unique labeled). This branching strategy works best if only one version is in production and releases should always contain everything made.

2.In which cases is ancestry information not kept?

If files are copied or branches are destroyed. However if you need to delete and/or recreate branches all the time and/or need to use acceptTheirs continuously, than often its an indication of; inadequate branching strategy, inadequate TFS training, or issues with the testing and patching strategy (bugs found in production and development are found and fixed at the same time, resulting in merge conflicts).

Upvotes: 2

Related Questions