7

What are the branching characteristics of TFS?

Early Branching/Heavy Branching

If we look at the tools Perforce, Subversion, CVS, for instance, we see that branching is taking a copy of the trunk. It is "early branching" all of the files which are defined to be branched, irrespective of whether those files are changed in that branch.

This methodology starts creating new versions of files, at the time the decision to create a branch is made, for the entire tree of files.

One of the biggest disadvantages is that any changes made outside that branch (typically in the trunk), that you want to bring into the branch, require per-file merges inwards of these files as they have "early branched."

Late Branching/Cheap Branching

In comparison with more recent tools - for example - ClearCase, Plastic SCM, AccuRev, Mercurial, Git - we see a late (cheap) branching policy.

We see that first new versions in a branch are only created when a file is checked in on a branch.

This means that when changes happen on the trunk that you wish to rebase into your branch, no merges for unchanged files occur.

How does TFS behave?

caveats: I note my terminology is not exact when we consider DVCS tools. I recognise Perforce has a round-about way of overlaying views but it's not done without great labour.

polyglot
  • 2,031
  • 2
  • 20
  • 28

4 Answers4

3

I'm told TFS is closer to the former than the latter.

James Polley
  • 7,977
  • 2
  • 29
  • 33
3

Note: the Version Control (ex Branching and Merging) Guide can help here.

In the "Single Dev Team Scenario 2.0.pdf" document of TFS Branching Guide - Lab.zip file, you will see that the creation of a branch is followed by a commit (a checking of all files from the original branch.
The space used is minimized, as described in Isolation for Collaboration page:

When you create a new branch and commit, all of the files in the new branch that are identical to the files in the source branch point to the same content.
The result is that a branch consumes very little additional storage space, and that storage space expands only when the branched file becomes different than the source.
And even when files change, Team Foundation Server employs a differencing engine to analyze changes between files and once again optimize storage space.

So it is heavy branching for TFS2008 (with space optimization).

In TFS2010, branches are first class object and easily separated from simple folders.

TFS branches

Amittai Shapira
  • 3,749
  • 1
  • 30
  • 54
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • That's a major improvement at least. The branching plans on their website are quite immature. The examples are to have a branch called dev and a branch called release, and there's little mention of retiring them. Far better to create new branches on a per release to make it easier for the merge algorithms to get it right, and have a common ancestor that isn't 3 years old, for example. – polyglot Dec 30 '09 at 15:20
  • There is actually quite a bit of very useful and detailed guidance available @ http://www.codeplex.com/BranchingGuidance/. The site referred to above is an in progress revisit to the original guidance I mention here. All techniques for implementing branching apply across version control systems. Some systems make certain aspects of these techniques easier than others, but they can generally be applied throughout. – Ryan Cromwell Dec 31 '09 at 02:09
  • @Ryan Cromwell thank you for the other link. I refer now to both guides in my edited answer. – VonC Dec 31 '09 at 06:22
  • @polyglot: I agree completely with your analysis. The TFS branching model is not optimal, to say the least ;) – VonC Dec 31 '09 at 16:52
  • @AmittaiShapira Thank you for the edit, updating that link. – VonC Mar 22 '18 at 13:46
3

I was on TFS for 5 years and recently switched to GIT in the last year.

There are two major disadvantages to TFS (vs GIT):

1) No Rebase concept. All branch-to-branch interaction is merge. The merge clobbers changeset history, and hides all of the useful details in the commit comments. No Cherry-pick, no timeline rebuild. This leads to endless parent walks, and serious research to determine the history of a changeset.

2) Baseless merge is a nightmare. In TFS, if you did not happen to build the branch relationships 6 months ago, you are going to have to reverse/forward integrate many many times to get to your destination trunk. In git, all trunks are compatible all of the time.

TFS works, but has road-blocks. Some of the road-blocks have really hurt our delivery timelines.

So far, we have been doing some pretty advanced things with GIT in an Agile Team environment and have always been able to meet each new source problem with a solution in minutes not hours or days. Tiers of Promotion are abstract, and can be swapped ad-hoc. Developers can share changesets 'node-to-node', and collaborate on work before pushing to a common repo.

No offense to MS, but I just cannot get behind a tool that has so many obstacles out-of-the-box.

Todd
  • 31
  • 1
0

When you create a branch in tfs 2008 you have to checkin the new branched files first. Once you check them in the versioning of the branch starts separate from the original. You can also track history of branched files before they have been branched but you need to install TFS Follow Branch History Add-in for VS

Branislav Abadjimarinov
  • 5,101
  • 3
  • 35
  • 44