Note that a deliver is not in any real sense a "physical copy" ... it is
just a manipulation of some SCM meta-data, often resulting in not much
more than the update of a few database references.

Cheers,
Geoff

Chemi wrote:

Chemi wrote:
Hi, reading Workshop material (Project growth and multi-stream dev
presentation) it seems we need to copy physically (deliver and accept)
the component in an "integration" stream as communication stream
between teams.

Is there any update about this topic in RTC 2.0 so a physical copy is
not needed? Reading What's New I didn't find anything.

Thanks in advance,

Chemi.

I found discussion thread "Easy means for multiple streams to share a
component and always latest changes in that component" where it is
discussed another interesting way to achieve this. Not physical copy of
the shared component is needed.

Regards,

Chemi.

Note that it is important to distinguish "a configuration of a
component" from "a component". In particular, multiple streams can
share the same "component", but each stream has its own "configuration
of that component". So if you update the configuration of a component
in one stream (via a deliver operation), it never automatically updates
the configuration of that component in a different stream.

Some poorly designed SCM systems allow two configurations to "share" a
configuration of a component (where an update to the configuration of
that component in one stream automatically updates the configuration of
that component in another stream). The reason I call such SCM systems
"poorly designed" is that the "configuration of a stream" is the most
important SCM object to control ... it is the object that defines the
"product" of an implementation effort (i.e., what you will be delivering
to your customer).

So developers need to be aware of all the streams they are modifying
when they deliver ... so that if the deliver violates the process of one
of those streams, they know which stream it is.

Note that in Jazz SCM, you can define a workspace to "flow" to multiple
streams, and you can configure the pending changes view to show you all
of those target streams, rather than the default which is to just show
the flow target marked as "current". This lets you see what the
relationships are between your workspace and all of the streams you are
delivering to.

WRT my earlier note about a "physical copy" vs. a "logical copy". That
was just to make sure folks knew that you aren't paying the cost of
physically copying all of the files in the workspace to the stream when
they do a deliver. One of the main reasons SCM systems provide this
"shared configuration" capability is that they actually do make physical
copies on deliver, and the shared configuration "feature" is just a hack
to avoid that overhead. They then try to characterize this bug as a
"feature" (:-). Jazz SCM optimizes the performance of deliver, so that
deliver process can be properly enforced while still getting fast delivers.

Cheers,
Geoff


Chemi wrote:

Hi Geoff. Thanks for your comment.
But I have another question then... because, if anybody update the code
in Stream A, people using that "logical copy" from Stream B won't see
any update until somebody deliver the same changes to Stream B. Right?
That is the reason I thought a physical copy was performed. Am I
correct? If there is not a physical copy, why Stream B doesn't see the
updates? Is there any white paper commenting deeply this behavior (I
have read overviews, and InfoCenter but I didn't really found such deep
concepts).

Thanks again,

Chemi.

Geoffrey Clemm wrote:
Note that a deliver is not in any real sense a "physical copy" ... it
is just a manipulation of some SCM meta-data, often resulting in not
much more than the update of a few database references.

Cheers,
Geoff