Doug Neumann, our PM, posted on the Team Foundation newsgroupmicrosoft.private.whidbey.teamsystem.teamfoundation newsgroup a nice answer to a question about branching models and VSTS.

Question (Carl Daniel):

IEEE Computer, September 2002 issue contained an article entitled “the importance of branching models in SCM”. Since we can’t really evaluate the Team System SCM without the server component, perhaps someone from the Team System team at MSFT could comment on how Team System SCM fits into thebranching scenarios described in this article.

The article is also available at http://www.seapine.com/pub/papers/SCMBranchingModels.pdf in case you don’t have IEEE Computer handy.

Answer (Doug Neumann):

That’s a good article, thanks for the pointer.

The answer to your question is that we give you the tools to implement any of the models outlined in this article.

Here’s a quick overview of the power of branching and merging in the VS Team System:

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

The authors of this article seem rather partial to their “Branch by Purpose” model, so let’s talk about how that would work in the Team System.

We’ll setup a mainline for most of our development work and put it in the repository at $/Application/Main. During the development phase, all of our new features and bug fixes are going into this line. When we are feature complete, we branch the main line to work on one or more release branches. To keep it simple, let’s say we’ve got a single release branch which we’ll put at $/Application/Release. If we have other feature work that we want to occur in parallel, we could also branch the main line to create a bridge branch at $/Application/Bridge.

After feature complete, we enter the “code chill” mode where we’re only submitting bug fixes to the main line. We have some cool mechanism in VSTS that will allow you to control what changes can get checked into the mainline during this period (if you want to hear about those, post another follow-up). At any time, we can run a query to get a list of all changesets that have been committed to the main line but not merged to the release branch. We can then cherry-pick those changes as necessary (we don’t have to take them all) or merge over all changes if desired.

When we stabilize that release line, we enter code freeze at which point release candidates are produced. According to the article, any fixes needed for the release candidate are checked directly into the release branch, although I don’t see why they couldn’t also follow the model of code chill. Either way, you can merge the changes either direction between the main line and the release branch to make sure the fix is in both places.

In the article, they branch for the actual release, but they don’t show any changes on this branch. If it’s not going to evolve, you can accomplish the same goal by slapping a label on the items that were included in the release. If you determine later on that you need to make changes to the release, you can always create the new branch from the label. If you’re going to be releasing hotfixes for individual bugs, you might want to branch for each hotfix and then merge the changes back into the release branch (where your maintenance work is happening).

Hope that helps. Post a follow-up if you’d like more detail. Also, I’d be interested to hear what you think of the strategies in this article. I have my own philosophy on this stuff that I’ll save for another time.