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?
Thoughts about agile software development, software configuration management, and the intersection between them.
Subscribe to:
Post Comments (Atom)
Lessons in Change from the Classroom
This is adapted from a story I shared at the Fearless Change Campfire on 22 Sep 2023 I’ve always been someone to ask questions about id...
-
My main development language is Java, but I also some work in Python for deployment and related tools. Being a big fan of unit testing I wr...
-
This is a bit off of the usual “Software Development/Agile/SCM” theme that I usually follow, but it does fit into the theme of accidental si...
-
Being a fan of Continuous Delivery , identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number...
1 comment:
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).
Post a Comment