RTC Source Code between streams (StreamA and StreamB)
We are planning to RTC Source Code Managment now, for one of the Banking project.
I would like to under stand the flow of changes from StreamA to StreamB, how to share the code between two streams? and does it affect when we share the code between streams ( Development Streams wanted to share some code with Maintannce stream only few defects fix has to be shared with other streams.(eg: two fixes out of 5 fixes). How to share only few changes? do we need to create Baseline. If we replace with Basline, it will replace the existing code with content in the baseline.. please let me know how to proceed does it affect on the existing code. It would be great if you could help me in getting some basic understanding. Currently we have only one Main Development Stream and two components for Codeing and Documentations. we have different functional areas like 14.. we are planning to create streams for each functional Area. Scenrio.. How do I share the changes from one stream to another. whos responsbility is it Developer or CM if the develpment is going on .. we have Pre-SIT, SIT and UAT. changes flowing from the development stream to the two maintenance streams. When it comes for integartion stream, is that activity is responsible for Developer or CM |
4 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 27 '11, 10:23 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
On 12/27/2011 5:53 AM, sriramak wrote:
We are planning to RTC Source Code Managment now, for one of the To share only a few changes, you would use change sets, not baselines. First a general piece of guidance. If you are performing a change that needs to be applied to multiple releases (e.g., a bug-fix), it is best to perform the fix on the earliest release it needs to be applied to, and then merge all the fixes forward to the later streams. So in your case, if you have a bug-fix, apply it to Maintenance first, and then merge it forward into Development. Now back to your question, to share code between RTC streams, you would normally create a repository workspace on the "destination" stream (the stream to which the changes should flow), and then change the flow target of that workspace to be the "source" stream (the stream from which you are getting the changes). Then, show that repository workspace in the Pending Changes view (you can start without loading any files, but if you need to perform any merges, you will have to first load the files to be merged before you can merge them). Then, in the Pending Changes view, accept the changes (change sets) that you want to flow to the destination stream. If there are any "gap conflicts", i.e. change sets that depend on change sets that you do not want to flow, then you will have to bring those change sets (the one with gaps) into your workspace as "patches". If there are any "merge conflicts", the Pending Changes view will guide you through the merge process. Once you have done any merging or patching required, you then should run your regression tests on the repository workspace, and if all are successful, change the flow target of your repository workspace back to be the "destination" stream, and Deliver the changes. If we replace with Basline, it will replace the existing code with Replacing the existing code in the Maintenance stream with a baseline from the Development stream will just make your Maintenance stream identical to that state of the Development stream, which is not what you want. Currently we have only one Main Development Stream and two components You would create separate streams if you want to run two development efforts in parallel. You'd only create a separate stream for each functional area if each functional area wanted to do its development in parallel with all the others. Scenrio.. How do I share the changes from one stream to another. whos Either way ... it's up to you. It depends on who is more capable of doing the merges when there are conflicts. if the develpment is going on .. we have Pre-SIT, SIT and UAT. You'll have to expand on what you mean by that. I'm guessing these are three different "promotion levels", based on the degree of testing they've received? If so, you'll probably want to create a separate stream for each one. changes flowing from the development stream to the two maintenance As indicated above, it would be better to flow changes from the two maintenance streams to the development stream. When it comes for integartion stream, is that activity is responsible Same as above ... either way is fine ... it just depends on who is more capable of doing any merges that might be required. Cheers, Geoff |
|
Hi Geoff,
Thanks for all the information... We have 14 Feature Streams for 1 Componenet.. if it is stream is redirecting to Development Stream ( Target Stream) in Flow Diagram.. Do I need to move the files from Stream1 to Target Stream Manually... ( for all 14 Functional Stream) Please let me know if any thing were we can automate to move all the information from Stream1 to Target stream.. REgards, Sriramk On 12/27/2011 5:53 AM, sriramak wrote: We are planning to RTC Source Code Managment now, for one of the To share only a few changes, you would use change sets, not baselines. First a general piece of guidance. If you are performing a change that needs to be applied to multiple releases (e.g., a bug-fix), it is best to perform the fix on the earliest release it needs to be applied to, and then merge all the fixes forward to the later streams. So in your case, if you have a bug-fix, apply it to Maintenance first, and then merge it forward into Development. Now back to your question, to share code between RTC streams, you would normally create a repository workspace on the "destination" stream (the stream to which the changes should flow), and then change the flow target of that workspace to be the "source" stream (the stream from which you are getting the changes). Then, show that repository workspace in the Pending Changes view (you can start without loading any files, but if you need to perform any merges, you will have to first load the files to be merged before you can merge them). Then, in the Pending Changes view, accept the changes (change sets) that you want to flow to the destination stream. If there are any "gap conflicts", i.e. change sets that depend on change sets that you do not want to flow, then you will have to bring those change sets (the one with gaps) into your workspace as "patches". If there are any "merge conflicts", the Pending Changes view will guide you through the merge process. Once you have done any merging or patching required, you then should run your regression tests on the repository workspace, and if all are successful, change the flow target of your repository workspace back to be the "destination" stream, and Deliver the changes. If we replace with Basline, it will replace the existing code with Replacing the existing code in the Maintenance stream with a baseline from the Development stream will just make your Maintenance stream identical to that state of the Development stream, which is not what you want. Currently we have only one Main Development Stream and two components You would create separate streams if you want to run two development efforts in parallel. You'd only create a separate stream for each functional area if each functional area wanted to do its development in parallel with all the others. Scenrio.. How do I share the changes from one stream to another. whos Either way ... it's up to you. It depends on who is more capable of doing the merges when there are conflicts. if the develpment is going on .. we have Pre-SIT, SIT and UAT. You'll have to expand on what you mean by that. I'm guessing these are three different "promotion levels", based on the degree of testing they've received? If so, you'll probably want to create a separate stream for each one. changes flowing from the development stream to the two maintenance As indicated above, it would be better to flow changes from the two maintenance streams to the development stream. When it comes for integartion stream, is that activity is responsible Same as above ... either way is fine ... it just depends on who is more capable of doing any merges that might be required. Cheers, Geoff |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Jan 08 '12, 12:55 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The easiest way to transfer changes from one stream to another is to use the Pending Changes view, and the "Deliver" operation. If there are no conflicts to be resolved, you can deliver directly from the source stream to the target stream. If there are conflicts to be resolved, you will need to use/create a workspace on the source stream, load it, accept changes from the target stream and resolve the conflicts, and deliver the result to the target stream.
Cheers, Geoff Hi Geoff, On 12/27/2011 5:53 AM, sriramak wrote: We are planning to RTC Source Code Managment now, for one of the To share only a few changes, you would use change sets, not baselines. First a general piece of guidance. If you are performing a change that needs to be applied to multiple releases (e.g., a bug-fix), it is best to perform the fix on the earliest release it needs to be applied to, and then merge all the fixes forward to the later streams. So in your case, if you have a bug-fix, apply it to Maintenance first, and then merge it forward into Development. Now back to your question, to share code between RTC streams, you would normally create a repository workspace on the "destination" stream (the stream to which the changes should flow), and then change the flow target of that workspace to be the "source" stream (the stream from which you are getting the changes). Then, show that repository workspace in the Pending Changes view (you can start without loading any files, but if you need to perform any merges, you will have to first load the files to be merged before you can merge them). Then, in the Pending Changes view, accept the changes (change sets) that you want to flow to the destination stream. If there are any "gap conflicts", i.e. change sets that depend on change sets that you do not want to flow, then you will have to bring those change sets (the one with gaps) into your workspace as "patches". If there are any "merge conflicts", the Pending Changes view will guide you through the merge process. Once you have done any merging or patching required, you then should run your regression tests on the repository workspace, and if all are successful, change the flow target of your repository workspace back to be the "destination" stream, and Deliver the changes. If we replace with Basline, it will replace the existing code with Replacing the existing code in the Maintenance stream with a baseline from the Development stream will just make your Maintenance stream identical to that state of the Development stream, which is not what you want. Currently we have only one Main Development Stream and two components You would create separate streams if you want to run two development efforts in parallel. You'd only create a separate stream for each functional area if each functional area wanted to do its development in parallel with all the others. Scenrio.. How do I share the changes from one stream to another. whos Either way ... it's up to you. It depends on who is more capable of doing the merges when there are conflicts. if the develpment is going on .. we have Pre-SIT, SIT and UAT. You'll have to expand on what you mean by that. I'm guessing these are three different "promotion levels", based on the degree of testing they've received? If so, you'll probably want to create a separate stream for each one. changes flowing from the development stream to the two maintenance As indicated above, it would be better to flow changes from the two maintenance streams to the development stream. When it comes for integartion stream, is that activity is responsible Same as above ... either way is fine ... it just depends on who is more capable of doing any merges that might be required. Cheers, Geoff |
|
Thanks Geoff,
Can you please provide me the steps for sharing changes directly from Stream1 to Stream2 ( when Stream2 is target stream for Stream1) Does it automatically flows into target stream when there is no conflicts.. Regards, Sriramak. The easiest way to transfer changes from one stream to another is to use the Pending Changes view, and the "Deliver" operation. If there are no conflicts to be resolved, you can deliver directly from the source stream to the target stream. If there are conflicts to be resolved, you will need to use/create a workspace on the source stream, load it, accept changes from the target stream and resolve the conflicts, and deliver the result to the target stream. Hi Geoff, On 12/27/2011 5:53 AM, sriramak wrote: We are planning to RTC Source Code Managment now, for one of the To share only a few changes, you would use change sets, not baselines. First a general piece of guidance. If you are performing a change that needs to be applied to multiple releases (e.g., a bug-fix), it is best to perform the fix on the earliest release it needs to be applied to, and then merge all the fixes forward to the later streams. So in your case, if you have a bug-fix, apply it to Maintenance first, and then merge it forward into Development. Now back to your question, to share code between RTC streams, you would normally create a repository workspace on the "destination" stream (the stream to which the changes should flow), and then change the flow target of that workspace to be the "source" stream (the stream from which you are getting the changes). Then, show that repository workspace in the Pending Changes view (you can start without loading any files, but if you need to perform any merges, you will have to first load the files to be merged before you can merge them). Then, in the Pending Changes view, accept the changes (change sets) that you want to flow to the destination stream. If there are any "gap conflicts", i.e. change sets that depend on change sets that you do not want to flow, then you will have to bring those change sets (the one with gaps) into your workspace as "patches". If there are any "merge conflicts", the Pending Changes view will guide you through the merge process. Once you have done any merging or patching required, you then should run your regression tests on the repository workspace, and if all are successful, change the flow target of your repository workspace back to be the "destination" stream, and Deliver the changes. If we replace with Basline, it will replace the existing code with Replacing the existing code in the Maintenance stream with a baseline from the Development stream will just make your Maintenance stream identical to that state of the Development stream, which is not what you want. Currently we have only one Main Development Stream and two components You would create separate streams if you want to run two development efforts in parallel. You'd only create a separate stream for each functional area if each functional area wanted to do its development in parallel with all the others. Scenrio.. How do I share the changes from one stream to another. whos Either way ... it's up to you. It depends on who is more capable of doing the merges when there are conflicts. if the develpment is going on .. we have Pre-SIT, SIT and UAT. You'll have to expand on what you mean by that. I'm guessing these are three different "promotion levels", based on the degree of testing they've received? If so, you'll probably want to create a separate stream for each one. changes flowing from the development stream to the two maintenance As indicated above, it would be better to flow changes from the two maintenance streams to the development stream. When it comes for integartion stream, is that activity is responsible Same as above ... either way is fine ... it just depends on who is more capable of doing any merges that might be required. Cheers, Geoff |
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.