Branching Is Not Just for Version Control

Printer-friendly version

Configuration management (CM) professionals and developers should go through various version control tools to see which has the best merging capabilities, the best history browsers, and the best branching mechanisms. For this story I want to focus on branching mechanisms, because a branching strategy is central to any configuration management plan.

Major branches typically refer to “release” or “development stream” branching; you create a new, persistent branch for release two and then another for release three and so forth. Minor branches refer to when you branch to avoid a concurrent change conflict and then merge the branch back upon check-in (a.k.a. commit). Branching makes parallel development and support possible. Subversion has a whole strategy on repository architecture to support major branches (see Recommended Repository Layout in the User Guide).

While it’s no wonder that we spend time making sure we pick the right version control tool, remember that in the full application lifecycle, branching goes beyond version control of the files. It’s not just the files that have to be organized—it’s the entire CM and application lifecycle management (ALM) data repository.

In the 1990s, Neuma Technology introduced the term “stream” (as in a development stream) to identify major branches that persist over time and around which repository data needs to be organized. The use of development streams across the ALM function is cited as the "number two" best practice in my list of the top twenty CM best practices.

Streams (“stream” branches) are critical, not just for organizing data in the CM repository, but for simplifying the data navigation and other user-interface functions of a software configuration management (SCM) and application lifecycle management (ALM) tool. You need to know which development stream you’re looking at in order to get most of the useful information from a tool; which file revisions are used to support release two; and which are used for the latest release in development. Those familiar with version control understand why these stream branches are required for tracking files against releases.

You also need to consider these questions: Which problem reports are outstanding in a given stream? How are past and future product requirements and team member activities allocated to release streams? How have verification results improved from stream to stream? In this instance, the word “stream” refers not only to major source tree branches, but to the “branches” of data across the ALM environment. For a more in-depth look at stream-based branching, be sure to read my piece on the subject.

The next time you think about creating a new release branch, keep in mind that you’re not just dealing with the source code; you’re dealing with the entire product repository. 

Printer-friendly version

Something to say? Leave a Comment

Joe Farah

President and CEO of Neuma Technology, Joe Farah is a regular contributor to the CM Journal. Prior to cofounding Neuma in 1990, he was a director of software at Mitel. In the 1970s, Joe developed the Program Library System (PLS), still heavily used by Nortel (Bell-Northern Research), where he worked at the time. He's been a software developer since the late 1960s.