Best practice for feature development: stream vs shared repository workspace?
I'm trying to understand the pros/cons of using a stream vs shared repository workspace for feature-level teams whose work is ultimately delivered to a higher level stream.
The course material for Configuring Projects in IBM RTC defines a stream as a permanent source control object, and shared repository workspace as temporary. As such, the course material recommends using shared repository workspaces for ad-hoc and feature development.
However, the IBM DeveloperWorks blog on "Managing parallel development in RTC" (http://www.ibm.com/developerworks/rational/library/parallel-development-rational-team-concert/index.html) advocates using streams for feature development and deleting them once the feature has been delivered to a higher level stream.
So given these two opposite recommendations, which is the best one? What are the pros and cons of each option?
For the most part they seem equivalent to me, although stream information is captured in the data warehouse, while repository workspace information is not.
Any ideas?
The course material for Configuring Projects in IBM RTC defines a stream as a permanent source control object, and shared repository workspace as temporary. As such, the course material recommends using shared repository workspaces for ad-hoc and feature development.
However, the IBM DeveloperWorks blog on "Managing parallel development in RTC" (http://www.ibm.com/developerworks/rational/library/parallel-development-rational-team-concert/index.html) advocates using streams for feature development and deleting them once the feature has been delivered to a higher level stream.
So given these two opposite recommendations, which is the best one? What are the pros and cons of each option?
For the most part they seem equivalent to me, although stream information is captured in the data warehouse, while repository workspace information is not.
Any ideas?
Accepted answer
Use a stream.
Streams are for sharing. Repository workspaces are not. They are the "private stream" of the user.
If the repository workspace is visible to the public or a scope, the repositry workspace is still owned by just the owning user and read-only for everyone else.
RTC SCM is designed around collaborating on streams and repository workspaces and streams are cheap.
Just a warning, If you as an owner load the repository workspace multiple times e.g. on different machines and change and deliver something on one of the instances, the other client gets confused and the workspace will be out of sync. Use multiple repository workspaces and a stream in situations like that.
Streams are for sharing. Repository workspaces are not. They are the "private stream" of the user.
If the repository workspace is visible to the public or a scope, the repositry workspace is still owned by just the owning user and read-only for everyone else.
RTC SCM is designed around collaborating on streams and repository workspaces and streams are cheap.
Just a warning, If you as an owner load the repository workspace multiple times e.g. on different machines and change and deliver something on one of the instances, the other client gets confused and the workspace will be out of sync. Use multiple repository workspaces and a stream in situations like that.
Comments
Thanks, Ralph, that makes sense. The IBM training material for Configuring Projects with IBM RTC should be changed, since their recommendation runs counter to what you are saying. Slides 58 and 59 of Module 4 in Configuring Projects in RTC v4.0.4 clearly recommend using shared repository workspaces over streams for ad-hoc, feature-level teams. I'm not sure if this has been corrected in later versions of the training materials...
I don't have access to that material, so I can't comment on it, really.