It's all about the answers!

Ask a question

If there is replace baseline from other stream, why deliver?


Jirong Hu (1.5k9295258) | asked Jul 27 '11, 11:10 a.m.
I am following this article to setup the same structure in RTC. While doing it I have this question:

1. Let's say I have a component in Vendor stream, have a baseline1.

2. In dev stream, initially included baseline1 of vendor component.

3. After add new release to vendor stream, created baseline2.

4. Next following the normal procedure, we should deliver new changes included in vendor baseline2 to dev stream. Maybe from dev workspace, change target to vendor workspace, deliver?

5. But instead of doing 4, I can do a replace component baseline1 with 2 directly in dev stream. Can I? What's the difference?

See, this tool is now too flexible, I am confused :+)

https://jazz.net/library/article/214/

Thanks
Jirong

5 answers



permanent link
Tim Mok (6.6k38) | answered Jul 27 '11, 12:13 p.m.
JAZZ DEVELOPER
I am following this article to setup the same structure in RTC. While doing it I have this question:

1. Let's say I have a component in Vendor stream, have a baseline1.

2. In dev stream, initially included baseline1 of vendor component.

3. After add new release to vendor stream, created baseline2.

4. Next following the normal procedure, we should deliver new changes included in vendor baseline2 to dev stream. Maybe from dev workspace, change target to vendor workspace, deliver?

5. But instead of doing 4, I can do a replace component baseline1 with 2 directly in dev stream. Can I? What's the difference?

See, this tool is now too flexible, I am confused :+)

https://jazz.net/library/article/214/

Thanks
Jirong

Replace will make the contents of the component in the stream the same as your workspace. If there are incoming changes, they will be removed from the stream. You would only want to use replace if there was a change in the stream that you wanted to discard (discard in your workspace first then replace in stream) or you wanted to change the configuration of your workspace (replace with latest from stream).

permanent link
Jirong Hu (1.5k9295258) | answered Jul 27 '11, 2:35 p.m.
I think probably is same as change a stream's foundation in ClearCase UCM?

Thanks
Jirong

permanent link
Geoffrey Clemm (30.1k33035) | answered Jul 27 '11, 10:49 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, although in ClearCase, you can only do this to a "read-only"
component in a stream.

Cheers,
Geoff

On 7/27/2011 2:38 PM, hujirong wrote:
I think probably is same as change a stream's foundation in ClearCase
UCM?

Thanks
Jirong

permanent link
Jirong Hu (1.5k9295258) | answered Aug 03 '11, 11:48 a.m.
So now I have a Vendor stream (baseline 2) and Development stream (baseline 1) and corresponding workspace Vendor workspace (baseline 1) and development workspace (baseline 2).

Now I need to deliver baseline 2 to Development workspace or Development stream?

1. If there is no changes in Development workspace, I can deliver to Development stream?

2. If there is changes in Development workspace, I need to deliver to Development workspace, merge the changes and then deliver from Development workspace to Development stream?

In CC UCM, stream is component baselines plus change set. Is this still the same in RTC? And now I am a bit confused with the purpose of a workspace. Feels like a snapshot view (sandbox as the ss view directory), but you can do deliver from workspace to stream. Can anyone help me here?

https://jazz.net/library/article/502/

Thanks
Jirong

permanent link
Geoffrey Clemm (30.1k33035) | answered Aug 03 '11, 3:43 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Comments below:

On 8/3/2011 11:53 AM, hujirong wrote:
So now I have a Vendor stream (baseline 2) and Development stream
(baseline 1) and corresponding workspace Vendor workspace (baseline
1) and development workspace (baseline 2).

Now I need to deliver baseline 2 to Development workspace or
Development stream?

What really matters is that you get the change sets ... in general, I
wouldn't spend too much time trying to figure out baseline flows ...
they can be confusing whenever there is any parallel development going on.

So what I'd ask is "do I need to accept changes from the vendor stream
into the development workspace and then deliver them to the development
stream?

And the answer to that is "yes".

1. If there is no changes in Development workspace, I can deliver to
Development stream?

Whether or not there are "changes" in a workspace is based on what your
current target is (i.e. "changes" are always relative to the
configuration of your current target). So if the current target of your
Dev workspace is the Dev stream, and there are no "changes", then there
is nothing to deliver from the Dev workspace to the Dev stream.

2. If there is changes in Development workspace, I need to deliver to
Development workspace, merge the changes and then deliver from
Development workspace to Development stream?

Changes in the Dev workspace WRT what? And what did you mean by
delivering from the Dev workspace to the Dev workspace? Perhaps you
meant accept changes from the Vendor stream, then merge the changes, and
then deliver to the Dev stream? If so, then yes.

In CC UCM, stream is component baselines plus change set. Is this
still the same in RTC? And now I am a bit confused with the purpose
of a workspace. Feels like a snapshot view, but you can do deliver
from workspace to stream. Can anyone help me here?

For understanding RTC change flow, I'd suggest ignoring baselines ...
they will confuse you (:-). Focus on the change sets. So in RTC, a
stream is a sequence of change sets (the "change set history" of the
stream).

From a CC perspective, think of your RTC repository workspace as your
CC dev stream, and your RTC sandbox as your CC snapshot view attached to
that CC dev stream.

Cheers,
Geoff

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.