Streams and Branches Part 1

Hey guys,

If you look around at the SCM market, you'll see a few 'stream-based' products. AccuRev, PureCM and the UCM implementation of ClearCase/ClearQuest.

Team Foundation Server, like Perforce, Subversion and many others can be categorized as branch/merge systems.

There have a been a lot of really good discussion about branching/merging versus streams. A really good one can be found at CM Crossroads.

I found that discussion really interesting and informative. Sometimes the best way to see if you really understand something is to try and explain it to someone else; that's why I wanted to post about my thoughts on streams, and how they might apply to Team Foundation Server.

Two things make understanding streams difficult. First, all of the stream-based vendors have a slightly different interpretation of what a stream is. And secondly, you can use a stream-based approach in such a way that it looks exactly like a branch/merge approach.

From my point of view, the difference between a stream-based approach becomes really evident when you follow a branch-on-task approach.

A branch-on-task approach means that you would create a branch for every task you are working on.

UCM implements this by asking developers to associate every check out with a work item (CQ calls these activities).

What conceptually happens under the covers is that a branch is created for this developer, and some meta-data is associated with that branch to record that work item that is associated with it. This private branch is created transparently, and the developer's workspace is populated with items from that branch.

As the developer is working, they are free to make intermediate check-ins into their private branch. It is literally a private branch, their own private sandbox, so they can do anything that they would like there.

Usually, in a stream-based product, a 'project' will be comprised of at least 1 integration stream, 1 baseline and many of these task-based streams.

When a developer finishes their work, they deliver it into the project's integration stream.

Conceptually, the tip of the developer's branch is merged with a collection, or integration branch.

Stream-based products abstract this merging operation; from the developer's point of view, they press a button and their work goes where it is supposed to go, and they can move onto the next task.

Usually, a project manager or release manager is responsible for working with the integration stream. They decide when an integration stream is stabile enough to produce a baseline. Future projects, and subsquently future integration streams, can be seeded from these baselines.

Some stream-based products like AccuRev enable you to cascade streams; so a deliver into one stream can make its way through a hierarchy of parent or child streams.

The stream-based products I mentioned earlier have features to make this branch-on-task approach easier to manage (you can imagine that you'll get a lot of task streams really fast if you have a very busy project.

I don't want to say much about whether a stream-basd approach is 'better' than a branch/merge approach. That is a really subjective topic because a lot really has to do with your prior experience and the dynamics of your team. I will say though that there seems to be some real benefits to using streams. For example:

• Seeing a list of task-based streams could add visiblity into a daily SCRUM meeting
• Since a developer's current work can be located on the server in a private branch, it would probably be easier to transition that work from one developer to another. This would probably be easier than pulling files from a local workspace.
• Isolating developers from merging branches is probably a good thing :)

So what does this mean for Team Foundation Server? Obviously doing branch-on-task without some rules for the road would be a disaster. Since it is getting late on a Sunday night, I'm going to wrap this post up; I'll talk about what a streams-basd approach might look like in Team Foundation Server in another post later this week.

Thanks!

Eric.