I was interested to browse information about Microsoft’s Team Foundation Server (TFS) 2010 and it’s newer features.
It made me think a little about how TFS has evolved and what is the comparison to Perforce. This is interesting because TFS shares a lot of principles with Perforce as regards the underlying model (integrations, branches etc) – not too surprising as Microsoft still uses their own re-badged version of Perforce called SourceDepot internally for some of their major projects (Windows and Office development). I doubt that TFS shares any code with Perforce/SourceDepot as Microsoft totally re-architected it on top of SQL Server and with different comms architecture etc.
It has been interesting to see how TFS has changed some of the functionality/terminology from the Perforce equivalents, and yet with similar underlying principles.
Perforce Branching and Merging
- Perforce has the integrate command which will both create a new codeline from an existing codeline, or propagate changes between codelines.
- Integrate has many options for source and target specifications, including wildcards and branch specifications (with complete set of view mappings), and options to selectively integrate specific changes
- The -v option does not copy files to the workspace (makes creation of new codelines faster)
- You need to run the resolve command after the integrate to decide how to merge changes, or whether to discard the source changes (but remember them as merged), or overwrite the target files, etc.
TFS Branching and Merging
- TFS has the branch command which creates new codelines from an existing codeline, and the merge command which propagates changes.
- TFS can only branch files or folders – it has no equivalent of branch specs
- The branch command has a /noget which is the equivalent of integrate -v.
- The merge command has a /discard option which is the equivalent of resolve -ay
- The resolve command does merges
Thoughts
Based on my experience of training people (for Perforce in particular), Perforce has more power/more options, but these take longer to learn. TFS has considered Perforce’s options and simplified and moved some functionality to different commands.
For example, I quite like the way TFS splits the branch and merge commands – users tend to think of these as distinct operations. Under the covers, it is understandable why Perforce treats them as similar, since for each individual file, creating a copy on a new codeline is the same whether you are creating the whole codeline or have added a new file and are propagating that single add sometime after the codelines have been created.
TFS First Class Branches
The TFS simplication of only allowing files or folders to be branched (folders recursively) is typically what most Perforce users do anyway – otherwise it starts to get very complicated to understand your repository structure.
In particular, this has allowed them to implement First Class Branches (from Matt Mitrik’s blog):
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
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…
