Branching models vs. Pinning and Sharing
At SDWest, I picked up Seapine Software's whitepaper,
Better Concurrent Development Through Branching. It has a great diagram of branching:
If, like me, you were weaned on Visual SourceSafe, you have a slightly distorted view of the world. As it turns out,
SourceSafe's pinning and sharing functionality is a poor man's substitute for real branching, as Buck Hodges
explains:
Branching and merging in TFS provide a more robust way to accomplish what sharing and pinning are often used for in VSS. In TFS, you would branch a directory (source), using the "branch source target" command, to the desired location (target). Then when there are changes in the source that you need in the target, you would use the "merge source target" command to propagate the changes. The merge command remembers what changes have have been brought over to the target, so it brings the target up to date with the source by only merging changes that have not been merged.
The Seapine whitepaper references a SCM paper titled
The Importance of Branching Models in SCM (pdf) which emphasizes that
branching is the backbone of any modern source control system, and outlines some different approaches to branching along with the pros and cons of each.
Buck Hodges has another post where he
outlines specificially how Team System is designed around branching:
- Path-space branching
Branches are created within the path
structure of the repository, similar to file copy operations. In
talking to users, we find that this model is much easier to visualize,
and is actually what they really want to do. They want a copy of the
source that can evolve asynchronously and that's what we give them. - Support for merging namespace changes
Many SCC systems focus on
merging content changes that have occurred to a specific file between 2
branches. We take a broader view of merging changes and focus on
merging all types of changes between branches. Thus, we're able to
merge file adds, deletes, moves, renames, etc. as part of your standard
merge operation. - Changesets
Changes that are committed together are managed as a
single entity called a changeset. Thus, when it comes time to merge a
change to a new branch, you don't have to wrack your brain trying to
figure out the full list of files you need to operate on. Just tell us
which changeset you want to merge and we'll do it all for you. - Cherry-pick merges
You can merge specific file change to
another branch without merging the changes that were included in
previous versions of those files. Thus, if you've got 2 bug fixes which
touch the same file, you can merge the second one without merging the
first. - Merge candidate queries
You can ask the system for a list of all changes which haven't yet been merged between 2 branches. - Merge history queries
You can ask the system for a list of all changes that have ever been merged between 2 branches.
Buck notes that the VSTS team is partial to the
Branch by Purpose model, which is outlined in the SCM paper:
If you're adapting to Team System, you'll definitely want to develop with branching in mind.