Team Foundation Server branching characteristics, compared to others

Question

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.

Answer 1

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.

Answer 2

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

Answer 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.