This is a book I read a little bit ago, but I thought it would be very useful for CM administrator who are trying to determine branching strategies in the system. One of the authors Brad Appleton is active on the Yahoo scm-patterns user group, and in CM Crossroads. His ACME project has a lot of great resources on it that I turn too often. The book is authored by Steve Berczuk with Brad Appleton who are both SCM branching methodolgy experts. They typcially think of branching and branching activities in ClearCase terms, so having an understanding of how ClearCase works will make reading this book a lot easier.
The general concept is to identify common patterns and situations that are ideal for creating branches, and each branch is used with a specific purpose in mind. There are many different reasons one might branch their source code and the book can be very complex when covering all the different scenario’s. The branching diagram shown in the beginning of the book is a big spider webby looking thing that almost resembles the history of UNIX diagram.
Even though there are many different branching patterns, there are really three major types which are discussed in the first couple chapters of the books. Mainline, Active Development line and Private Workspace. These are fairly simple concepts which is good since branching in SCM can have a tendency to be overly complex and hard to understand. In basic terms a Mainline can be used for maintaining active production stable code. The Active Development branch can be used for integration or to checkin changes and Private Workspace can be used to work in isolated environments. Code modifications go through a promotion steps from Private to Active to Development as changes are tested and approved.
When I work with Surround clients I call this the Reverse Waterfall approach. It is very popular for Web development as we tend to recommend Branch by Purpose for application developers which work almost in reverse. But the Reverse Waterfall approach is good for managing changes on a continuous basis, which maybe more appealing to agile development practices which integrate early and often, while branch by purpose is more traditional SDLC that pinpoints requirements and sets project goals based on time estimates to complete those requirements.
This was an important book for me to read and greatly added to the evolution of my understanding of branching, why people branch and what the positives and negatives behind branching. There is a lot of attention and detail paid to quality function like unit and regression testing and how to effectively use branches to perform these different function.
A recommended read for anyone trying to understand branching in SCM.
Posted by pat on Friday, August 18th, 2006 at 1:43 pm.
Loading ...
Thanks for the words of praise about my book with Steve. I’m glad you found it to be so valuable. I was hoping to clarify a few things you wrote above …
First off, I do have ClearCase experience. Steve did not at the time of the writing of the book- he does have Perforce experience. I tend to think of branches more like the way AccuRev uses the term streams (which is a bit different from both ClearCase and Perforce). A better, more thorough discussion of branching (and many more branching patterns) can be found in my “Streamed Lines” paper, which probably gives a more in depth treatment of how I tend to think about branching.
In your write-up above, it appears as if “Private Workspace” is a branching pattern. I just wanted to clarify that Private Workspace does not use branches. There are other patterns which may be used with a Private Workspace, like Task-Branch, or Private Versions, which can be implemented with a private- branch. Private Workspace is not a branch in a promotion lifecycle however.
The three major types of branches discussed in the book are Mainline, Release-Line, and Active-Development Line (or Active-Line). When changes are promoted, they go fro the Active-Line to the Release-Line, and then to the Mainline (if the Mainline and Release-Line happen to be separate branches).
This is actually well aligned with “Branch by Purpose” (at least based on some correspondence I had with Chuck Walrad, one of the co-authors of the Branch-by-Purpose paper). Both Branch-by-Purpose and Mainline are really about how to structure branches (not an individual branch). And both say that instead of branching by release-number (what our book calls staircase branching) to instead use “project-oriented” branching.
So the Active -to- Release -to- Mainline actually is not an instance of waterfall branching, nor of reverse waterfall branching. Because the branches correspond nether to cascading staircases, nor to development phases. They instead correspond to a nested (rather than waterfall or reverse-waterfall) set of “quality filters”: where each “branch” makes a progressively higher tradeoff in favor of higher quality/stability over lower productivity/progress because builds and development need to happen less frequently and less rapidly on the later branches.
Thanks again for the kind review, and the opportunity to clarify some of the things written above!
Left by Brad Appleton on August 26th, 2006