Team Foundation Server and branching characteristics, compared to others

Question

What are the branching characteristics of TFS? I am asking the question because I don't have experience of the tool.

Let me discuss what context I am putting it in...

---

Early Branching/Heavy Branching

If we look at the tools Perforce, Subversion, CVS, for instance, we see that branching is effectively taking a copy of the trunk. i.e. it is "early branching" of all elements which are defined to be branched, irrespective of whether those items are changed by the work that is done in that branch.

This methodology starts creating versions at the time the decision to create a branch is made for the entire tree of files. Any changes made outside that branch, that you want brought into the branch mean that you have to do merges inwards of these items as they have "early branched."

Late Branching/Cheap Branching

In comparison with more sophisticated, later-generation tools - for example, if we look at ClearCase, Plastic SCM, Accurev, Mercurial, Git - we see a late (cheap) branching policy.

That is to say that in effect the first versions created are created when a file is checked in on a branch.

This means that when changes happen outside the branch, that you wish to rebase to, a rebasing of the branch definition leads to no merge to occur on the branch.

---

Has anyone had a look at this issue, have they used and evaluated TFS, and what have they found?

thanks in advance

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.

Answer 1

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

Answer 2

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

Answer 3

Note: the Microsoft Team Foundation Server Branching Guidance (or TFS branching Guide, an in progress revisit of the first one, as mentioned by Ryan Cromwell in the comments) 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.