CM: The Next Generation of SCM Standards

suffice.  For example, there are Requirements, Activities, Problems, Documentation, Source Code, Test Cases, Test Results, and so forth.  Some might argue that there should be branches for each of these things, but I think that's trying to shoe-horn a natural process into a square container.  Yes, Requirements need branches (e.g. release 1 requirement tree vs. release 2 requirement tree).  So do some forms of Documentation and Source Code. But "activities" should be specific to a development stream - no branching.  Problems might apply to multiple streams, but certainly its the solution or fix that is tracked against each.  

And depending on the granularity of your test cases, it might be natural (coarse granularity) or overkill (fine granularity) to have branching, although certainly some fine-grained test cases will apply to specific releases.  The more natural approach here is to tag fine-grained Test Cases with the streams to which they apply.  Similarly, Activities and Changes should be tagged with the stream to which each one applies.

There's a bit more in this case though.  Unlike the other terms, this term involves evolution over time.  So Stream History, or Branch History, is important.  For example, a Change made in release 2 will, in the vast majority of cases, be applicable to releases 3 and 4. A problem fixed in release 2 will not appear in releases 3 and 4.  This assumes that release 3 is derrived from release 2 and release 4 from 3 (or at least 2 in this example).  This is an important term.  I like Stream and Stream History.  And what it comes down to is that the Stream History is the Branch History of the Product Container, whatever that may be in your CMDB/Process/Tools.  That is, how does my Product evolve.  

The reason I like Stream History (and Stream) over Branch History is that most, though not all, projects use a branching structure that does not reflect Stream History.  Hence, Branch History is a whole other consideration that's more applicable on a file/item by file/item basis.  There is a rather recent problem with the word Stream though - it has a different connotation in some exiting tools (e.g. Accurev).  So maybe Product Branch might be a good alternative.  Note that this term must implicitly be placed in the context of a Product (or Product Hierarchy, or whatever is "released" together).

My Vote:  Stream, Development Stream, Release Stream. Product Branch

Product vs. Project
Product, Project:  We all know what a product is and what a project is, don't we? So why would these two terms cause confusion in a development shop, some may ask.  Others know.  The primarily reason is the use of the term "Project" in IDEs, such as Eclipse and Microsoft's Visual Studio.  The IDEs want to focus on the project that is being completed as part of the development effort.  But in the end, the IDE project outlasts the Project.  In fact, Product would have been a better word, or perhaps Deliverable, Deliverable Set or Package.  An IDE project creates some deliverable(s). But when the release is all done, the IDE project persists to create the deliverables for the next release.  

Traditionally, a Project is a managed set of Activities, and this set of Activities culminates, frequently, in a release, be it a new Internal/External Release, a Variant Release or a milestone.  The Project is identified by a Work Breakdown Structure which outlines the activities to be performed.  An IDE may be used for some of these Activities (and a wider set in more recent IDE releases), but the IDE "project" is a misnomer.