First Class Branches

Introducing the concept of “first class branches” is a significant part of the 2010 release for version control.  Not only does it help to distinguish between folders and branches, but it enables our branch visualizations, and provides a platform on which to build other branch centric features in the future.  Since this improvement to branches is very central to several other features in 2010, I thought it was the logical place to start talking about version control features.

Its probably good to start by saying that we’re not reinventing the way that branching works in TFS.  Branches are still created in much the same way, our path spaced, early branching model hasn’t changed, and merging is fundamentally the same (see my post on slot mode).  What has changed is the presentation to the user, the representation of logical relationships, and the introduction of structured metadata.

Branches in the UI

Branches in SCE Now that branches are treated differently from other folders in the system, we have a new icon to visually distinguish them in the UI.  In Source Control Explorer, branches will continue behave just like folders, meaning that they are still containers of files and folders, and all of the same actions are present - they can be branched, merged, deleted, etc…

The context menu for branches also has some additional commands in 2010.  We’ve added a “Branching and Merging” sub-menu, which contains the advanced options for converting folders to branches (see Upgrade section below) and reparenting, and also provides the entry into the branch hierarchy visualization.

The properties view for branches is also different than that of ordinary folders or file, containing some metadata for the branch, relationship information, and permissions for the branch.


Creating New Branches

In TFS 2010, the creation of branches has been streamlined a bit from the process in 2008.  In 2008, creating a new branch was like every other action in the system – changes were pended on the client, and then checked in to the server.  Based on feedback from users, we’ve decided to bypass the step where changes are pended, and perform the branch creation entirely on the server.  With this approach, the round trip time for downloading a copy of each file on the branch and then uploading each file again has been eliminated. 

It is worth noting that the behavior for branching folders is unchanged for 2010, and the default behavior from the command line is to pend the branch locally (even when creating child branches).  The tf branch command also allows you to specify a “/noget” option which can give similar behavior for command line branching to the new default in the UI (this option actually existed in 2008).


One of the pieces of metadata that we’ve added to branches is the concept of an owner.  By default, the owner is the user that created the branch, and after a branch is created, this can be changed.  For this release, the owner field doesn’t have many restrictions besides being a valid user in the system.  The idea here is that this is the point of contact for the branch – pretty straightforward.


The relationships between branches is probably one of the most interesting additions for version control in TFS 2010.  This has enabled us to create all of the great visualizations that we’ve talked about in the past, and that users have requested for quite some time.  

Branch RelationshipsWhat we’ve done is to create the logical relationships that exist between branches, and to keep this separate from the physical relationships that exist between branches (as shown in SCE).  Using these parent-child relationships and the merge data that we store in the VC database, we can build all of the cool visualizations we’ve added in this release. 

In the properties window for each branch, we show a simple view of the relationships for a given branch, including its immediate children and lineage to the root of the branch hierarchy. 


To give finer control over who can merge into and create branches, we’ve added two new permissions related to branches – Merge and Manage branch.  The Merge permission determines just that – only users with the Merge permission for a given branch can pend merges on items on that branch.  The Manage Branch permission determines which users can update the metadata and relationships for a branch, and it also determines who can create new branches from a given branch.  There are a lot more details around the new permissions, so I’ll save that for a future post.


Since we’ve added this new concept of first class Branches in this release, and most existing TFS servers already have branches, there is a bit of work that needs done to enable existing servers to use these great features.  Our goal for RTM is to handle this automatically during the upgrade process, but in the interim the process is still very much a manual process. 

Hakan Eskici, one of the other program managers for TFS has been working on upgrading team projects to use new TFS 2010 features, and has posted several posts on the matter.  Check them out on his blog:

Enable Branch Visualization in Upgraded Team Projects (TFS 2010 Beta1)

Sample Script to Enable New Features in Upgraded Team Projects (TFS 2010 Beta1)