Sunday, August 16, 2009

Streamed Lines at 11

As I was starting to prepare for a class I'm giving at the Software Test and Performance conference in Cambridge MA this October I looked over a paper Brad Appleton and I wrote in 1998 on branching patterns: Streamed Lines, and I started to think about the path from this paper to the SCM Patterns book. Streamed Lines describes a number of branching patterns and when it's appropriate to use each one. From time to time people still tell me or Brad that this is one of the better overviews of branching strategies they have seen.

The paper grew out of material we gathered in a workshop at ChiliPLoP 1998 in Wickenberg AZ. We organized the set of index cards, categorized by color-coded stickers into the paper we prepared for workshopping at PLoP 98 (which was the PLoP conference I was program chair for). Many steps later, with encouragement from John Vlissides, we submitted a book proposal and started working on Software Configuration Management Patterns. The SCM Patterns book says a lot less about branching than Streamed Lines, and more about how SCM and version management practices fit into a pragmatic and agile development environment. Given how the book morphed from the original branching patterns, there is still a place for the information in Streamed Lines.

Streamed Lines may be due for an update to take into account how things like distributed version management systems like git and Mercurial affect the cost of branching. Regardless of tools, branching can have costs relative to not-branching; just because something is easy to do, does not mean that it's the right thing to do, but newer tooling is worth considering as you develop an SCM strategy.

Have you read Streamed Lines? Does it need an update? What would you change about it? How much should tools affect the principles it describes?

1 comment:

Jan Hollevoet said...

I read it! And referred to it. Nice work.

But a new edition would be a great.

In my experience, I only branched for patches and for supporting a release-prep codeline. But I avoid branching, mainly because of costs/time involved. But also not-branching absorbs time: I spent lots of time in convincing people not to branch, for instance in case of a product line development. So, in some sense I think it is useful to add alternatives to branching (as for instance, product line development).

Branching and Integration Time

Discussions about branching often focus on the wrong thing. Unintegrated code sitting around slows teams down, whether the code is in a bran...