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

Answer 1

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 2

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.

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

Answer 4

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