It's all about the answers!

Ask a question

RTC Question


Raj K (10222125) | asked Aug 22 '10, 1:12 p.m.
I am a novice in RTC. Here is the question I have to the experts here. What is the best way to do this. We have a development stream for main. So baseline is created at end of a sprint / development. Now QA ia testing the code & found a bug. So we create a new QA Bugfix stream (using the baseline that has the code that is being tested). Dev will continue to work ( on next sprint) and have created other baselines going forward in the main stream. The development team will fix the bug using the QA stream & at the end create a baseline after the fix. ( assuming QA is lagging by 4 weeks behind Dev). How do we merge the fixes to other baselines & the latest in Main/Deveopment ? I am trying to get an understanding of how RTC works & the concepts ?

Appreciate your help

Thanks
RK

7 answers



permanent link
Shashikant Padur (4.2k27) | answered Aug 22 '10, 11:52 p.m.
JAZZ DEVELOPER
I am a novice in RTC. Here is the question I have to the experts here. What is the best way to do this. We have a development stream for main. So baseline is created at end of a sprint / development. Now QA ia testing the code & found a bug. So we create a new QA Bugfix stream (using the baseline that has the code that is being tested). Dev will continue to work ( on next sprint) and have created other baselines going forward in the main stream. The development team will fix the bug using the QA stream & at the end create a baseline after the fix. ( assuming QA is lagging by 4 weeks behind Dev). How do we merge the fixes to other baselines & the latest in Main/Deveopment ? I am trying to get an understanding of how RTC works & the concepts ?

Appreciate your help

Thanks
RK


For merging to the latest Main, you just need to change the flow target (In pending changes view, right click on the Main workspace and select "Change Flow Target") to your QA stream. You will get your fix (baseline/change set) as an incoming change. Accept it and resolve any conflicts.

You cannot insert the change for the subsequent baselines that followed after you created the QA stream. If you need it for testing purposes, then you need to create another workspace/stream out of the baseline (which does not have the change) and do the same as mentioned above to get the change to the new workspace/stream.

permanent link
David Olsen (5237) | answered Aug 23 '10, 5:51 p.m.
JAZZ DEVELOPER
raj_ss wrote:
I am a novice in RTC. Here is the question I have to the experts here.
What is the best way to do this. We have a development stream for
main. So baseline is created at end of a sprint / development. Now QA
ia testing the code & found a bug. So we create a new QA Bugfix
stream (using the baseline that has the code that is being tested).

Is it really worth the effort of creating and maintaining a new QA
Bugfix stream? Could you just test and fix the defect in the main stream?

Dev will continue to work ( on next sprint) and have created other
baselines going forward in the main stream. The development team will
fix the bug using the QA stream & at the end create a baseline
after the fix. ( assuming QA is lagging by 4 weeks behind Dev). How
do we merge the fixes to other baselines & the latest in
Main/Deveopment ? I am trying to get an understanding of how RTC
works & the concepts ?

Assuming that you do need to have a separate QA Bugfix stream, then
there are two approaches for getting a fix into both the QA Bugfix
stream and the main stream:

1. Have each developer be responsible for delivering his change set into
each appropriate stream. When working on a QA bug fix, he would have a
repository workspace that flows with the QA Bugfix stream. When the bug
fix is complete and delivered, he would then switch to his repository
workspace that flows with the main stream, find the work item for the
bug fix, and accept the change set for that work item into his
repository workspace (by right clicking on the change set in the work
item and selecting Accept). He can then do any necessary merges and
other necessary integration of the change. When everything is ready, he
delivers the change set into the main stream, just like any other change.

2. Have a dedicated person for migrating the changes from the QA Bugfix
stream to the main stream. Developers would deliver a fix to the QA
Bugfix stream and not worry about pushing the same change to the main
stream. The person responsible for migrating the changes will have a
repository workspace that flows with both the QA Bugfix stream and the
main stream. From time to time, that person will set the current flow
target to be the QA Bugfix stream and accept all incoming changes. He
will do any necessary merges and testing to make sure nothing is broken.
Then he will change the current flow target to be the main stream and
deliver everything.

permanent link
Raj K (10222125) | answered Aug 23 '10, 10:29 p.m.
ok i am clear in my head now. Now what is the idea of making the target flow of the QA bugfix stream to be the main stream? I tried playing with this but don't see the changes flow from BugFix stream to Main Stream ( Stream to Stream). When is it appropriate to use this?

Thanks
RK

permanent link
Geoffrey Clemm (30.1k33035) | answered Aug 23 '10, 11:20 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Making one stream the flow target of another stream is just a "comment"
to other humans, telling them that you expect to see changes flowing
between those two streams. It has no semantic effect on anything in the
SCM system. To actually flow changes, you would need a workspace to
accept changes from one stream and deliver those changes to the other
stream.

Cheers,
Geoff

On 8/23/2010 10:37 PM, raj_ss wrote:
ok i am clear in my head now. Now what is the idea of
making the target flow of the QA bugfix stream to be
the main stream? I tried playing with this but don't see the changes
flow from BugFix stream to Main Stream ( Stream to Stream). When is it
appropriate to use this?

Thanks
RK

permanent link
Raj K (10222125) | answered Aug 24 '10, 10:09 a.m.
Thanks Geoff.

Making one stream the flow target of another stream is just a "comment"
to other humans, telling them that you expect to see changes flowing
between those two streams. It has no semantic effect on anything in the
SCM system. To actually flow changes, you would need a workspace to
accept changes from one stream and deliver those changes to the other
stream.

Cheers,
Geoff

permanent link
Israel Lazar (4599) | answered Mar 19 '11, 8:16 p.m.
How we can take old versions files that is in Old Baseline 2 that have WI defect,

Solved this defect , and deliver them to BL 2 and also to BL17 (our current BL) with out run over the cod

Without run over our cod in BL 17?

permanent link
Geoffrey Clemm (30.1k33035) | answered Mar 20 '11, 2:11 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I assume by "without running over our code in BL17", you mean that you
only want to apply the changes from the defect-fix, and not "overwrite"
the new code in BL17 with the old code in BL2.

There are several mechanisms in RTC that virtually guarantee that this
will not happen by mistake.

In particular, one common approach for this scenario would be to select
a workspace associated with BL17, and then to "accept" into the
workspace the change set that fixed that defect (just go to the workitem
for the defect, and accept the change set associated with that defect).
Accepting that change set will not pull in any other changes from BL2
.... in particular, RTC will notice if the change set depends on other
BL2 changes, and if so, will not bring in any of the dependent changes,
but rather will create a "patch" which contains just the bug-fix changes
(after popping up a dialog box to confirm that you want to create a patch).

Cheers,
Geoff


On 3/19/2011 8:23 PM, ilazar wrote:
How we can take old versions files that is in Old Baseline 2 that have
WI defect,

Solved this defect , and deliver them to BL 2 and also to BL17 (our
current BL) with out run over the cod

Without run over our cod in BL 17?

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.