- First we had no branching support
- Then we had very primitive branching support at the physical level of individual files using funky looking numbers like 1.1.1.1 that were basically 4-level revision numbers
- Then we had better branching support, but still file-based, and it allowed us to use some reasonably readable-looking symbolic names to identify a branch
- Then we has support for branching at the project/product level across the entire configuration item
- Nowadays the better tools (such as AccuRev, ClearCase/UCM, Subversion, OurayCM, SpectrumSCM, Neuma CM+, and others) have "streams"
Streams are, in a sense, giving a view of a codeline that is similar to a web portal. They are a "code portal" that pulls the right sets of elements and their versions into the "view" of the stream and eases the burden of configuration specification and selection by providing us this nice "portal."
So what might be next in the evolution of branches and branching after this notion of "code portal"?
- Will it be in the area of distribution across multiple sites and teams?
- Will it be in the area of coordination, collaboration and workflow?
- Will it be in the area of increasing scale? What would a "stream of streams" look like?
What do you think will be the next steps in the evolution of branching beyond "streams" and what do you think are the trends that will fuel the move in that direction?
4 comments:
Nowadays the better tools (such as AccuRev, ClearCase/UCM, Subversion, OurayCM, SpectrumSCM, Neuma CM+, and others) have "streams"
In what sense does Subversion support streams?
I would say Subversion supports "streams" to the extent that it provides project-oriented branches: when a branch is created, it is not a branch of a lone file, it is a branch of the entire project/product.
Streams, as AccuRev uses the term, are more than that. The essential thing about AccuRev streams is that they are related in a tree structure, and a stream can inherit changes from its parent, automatically. You promote a change up, and the change is propagated down automatically, immediately becoming available to developers working against sub-sub-streams etc. I don't know if this is a named pattern, but maybe it should be.
I acknowledge that "streams" in all of the various tools that support them have some noteworthy differences. CM+ streams are different (and support more stuff) than AccuRev streams, which are different from "streams" in OurayCM, which is different than SpectrumSCM, Hansky "Firefly", etc.
The key thing they all have in common which is fundamental to each of them is the notion of project/product-wide (what I called project-oriented) branching rather than file-based branching. It's the "next step of evolution" up from doing task-based commits and treating changes as change-sets (a single logical change across multiple files).
Once I acknowledge the benefits from atomic-commits and change-sets, the next evolutionary step is to have branches of "changes" rather than of "files". So a "stream" is a "flow of changes" from a particular source.
In terms of the notion of auto-propagation between streams as a pattern, take a look at the Change Propagation Queues pattern from the 1998 paper of branching patterns.
Post a Comment