Questions on Multiple Stream Development
I am also looking at multi-stream development and hope to clarify how it works.
Here's the flow diagram scenarios I come across 1. Acme_wkspc_tim_dev -> Acme-Development -> Acme-release_1-1 -> Acme-release-1-0 Just want to confirm that this does NOT imply that whenever Tim delivers his changesets to Acme-Development, the changes will automatically be delivered to Acme-release_1-1 and Acme-release-1-0. Tim will still have to change his repository workspace flow target to Acme-release_1-1 or Acme-release_1-0 if he wants the same changes to be applied to that stream. Is that correct? 2. Acme_wkspc_alan_dev --> Acme-release-1-0 (dotted link) Acme_wkspc_alan_dev -> Acme-Development (default and dotted link) Here we have 1 repository workspace pointing to multiple streams (release 1.0 and Development) Assuming Alan is working on the development stream and a fix is required for release-1-0. But the repository workspace contains the development code base. Apart from changing his flow target to point to the Acme-release-1-0, what does he need to do to change his repository workspace code base to that of Acme-release-1-0? Hope I am making sense here. Also, what exactly does default link mean here? Does it imply that it is the first stream linked to that particular workspace repository? Need to understand this urgently. Thanks for your clarification. |
2 answers
RTC will never automatically deliver changes. Changes must be manually delivered to any streams which should have them.
This is a bit tricky. If the code bases have not diverged mush, Tim may be able to deliver the change. However, it is more likely that the deliver would fail (because the release 1.0 stream is missing previous changes on which the fix is based). In this case, Tim would need to create a workspace based off the release 1.0 stream and accept the change set into that workspace. It is likely that this will cause a gap which results in the change being applied as a patch. Tim would need to create a new change set from the patch and deliver that to the release 1.0 stream.
Do you mean the default flow target? If so, that is the primary place where the user delivers changes made in the workspace. For example, the default flow target for my workspace is my Team stream and I usually deliver my changes there. However, in special cases, I may deliver my changes directly to our cross team integration stream (e.g. if it is an issue that needs an immediate fix). Hope this helps, |
Also, the flow targets listed for a stream are only there to show intent. If your Acme-Development stream has Acme-Release_1-0 in the flow table, it is only there to show the intent is to deliver changes to Acme-Development and they may eventually be delivered to Acme-Release_1-0. It is still up to a user to deliver the changes to both streams.
I would definitely create a workspace for the older release stream. It makes it much easier to manage deliveries and you can still accept change sets (possibly applied as a patch) from the other stream. When the old release stream and the current release stream start diverging, it becomes very confusing and difficult to use one workspace for both streams. There might be a lot of conflicts and incoming/outgoing changes that make it difficult to see the changes you're currently working on. |
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.