Saturday, October 29, 2005

Codelines as Code Portals

I've been thinking a bit about the evolution of branching capability in version control tools.
  • 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 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"
Among the differences between streams and project-oriented branches were that project-oriented branches were still only the changes that took place on that branch; whereas streams gave me a dynamically evolving "current configuration" of the entire item (not just the changes); And in many cases "streams" are first-class entities which can have other attributes as well.

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?
Maybe it will be all three! Maybe a stream of streams is a composite stream where the parent stream gave a virtual view across several (possibly remotely distributed) streams and repositories, but via a dynamic reference (rather than a copy), so that the current configuration was a view of the combined currenty configuration of each consitituent stream? (somewhat reminiscent of how composite baselines work in ClearCase/UCM)?

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?


Anonymous said...

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?

Brad Appleton said...

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.

Anonymous said...

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.

Brad Appleton said...

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.