Problem with Multiple steams
We have 2 streams, one for development and 1 for production maintenance. When we check in and deliver code it goes into the stream. When we submit a build, all change sets are reverted back to "outgoing" in the developers RTC client and removed from the stream, the change sets do remain in the developers workspace. Any suggestions would be greatly appreciated.
|
8 answers
On 2010/08/31 11:07, ashworth wrote:
We have 2 streams, one for development and 1 for production It sounds like running a build is causing the stream to be reverted to an earlier state, as if the stream contents were being replaced by an older snapshot or an older repository workspace. That doesn't normally happen when you run a build. Can you describe more about your setup and what happens when you "submit a build"? I suspect that your setup is a little unusual, but I'm not sure in what way. Why did you mention that you have two streams? Is this happening in both streams? Or just in one of them? |
It would help if we knew a little more about how your build process is set up, and how you are using your 2 streams. Here's some things I would look at:
Is your build process using it's own workspace, and what stream is the flow target of the build workspace pointing to? What flow target are the developer's workspace pointing to, when you say you check in a deliver? Could it be that your build process workspace and developer's workspace are the same, or sharing the same directory location? From the symptoms you are describing, it seems like your build process is overwriting the developer's workspace. This would be a problem. Are your developers using a flow target to the development stream, and your build process using a flow target to the production stream? If that is the case, is there anyone delivering changes between the 2 streams? Otherwise, it is not clear how you are using the 2 streams. Also, look at the history of one of the files that this is happening to, both before and after the build. Maybe there's some clues there too. |
On 2010/08/31 11:07, ashworth wrote: We have 2 streams, one for development and 1 for production It sounds like running a build is causing the stream to be reverted to an earlier state, as if the stream contents were being replaced by an older snapshot or an older repository workspace. That doesn't normally happen when you run a build. Can you describe more about your setup and what happens when you "submit a build"? I suspect that your setup is a little unusual, but I'm not sure in what way. Why did you mention that you have two streams? Is this happening in both streams? Or just in one of them? Both streams have the same problem. I've been doing builds on a single stream since March of this year. I just recently created a new stream from our GOLDEN build that was put in production on Saturday 8/28/10. Things seemed to work as documented, but now the stream are getting reverted back to a previous snapshot when a build is submitted. |
It would help if we knew a little more about how your build process is set up, and how you are using your 2 streams. Here's some things I would look at: The stream history has the change in it before the build is submitted, and after the build the change is history is back to the previous history. And the change set is back in my outgoing tree. I have tested both flow targets, the workspace flow target is set to the stream and the stream flow target is set to the workspace. I am pretty sure this is a simple configuration issue. Just have not found any docs that are helpful yet. Still reading... A little more detail on the scenario. load a component into eclipse from the desired stream. Change the component checkin and deliver. All histories match at this point. All file repositories match at this point. Submit the build. Stream history goes back to previous while the workspace stream keeps the history as it was after the change. Open "Pending Change" and there is your code again, ready to be delivered. This is very puzzling and has crippled our development team. |
It would help if we knew a little more about how your build process is set up, and how you are using your 2 streams. Here's some things I would look at: The stream history has the change in it before the build is submitted, and after the build the change is history is back to the previous history. And the change set is back in my outgoing tree. I have tested both flow targets, the workspace flow target is set to the stream and the stream flow target is set to the workspace. I am pretty sure this is a simple configuration issue. Just have not found any docs that are helpful yet. Still reading... A little more detail on the scenario. load a component into eclipse from the desired stream. Change the component checkin and deliver. All histories match at this point. All file repositories match at this point. Submit the build. Stream history goes back to previous while the workspace stream keeps the history as it was after the change. Open "Pending Change" and there is your code again, ready to be delivered. This is very puzzling and has crippled our development team. I also upgraded my RTC client to the lastest versoin 2.0.0.2 fp 3 |
|
On 2010/08/31 15:52, ashworth wrote:
A little more detail on the scenario. load a component into eclipse How is your build configured? What repository workspace is the build definition pointing to? What are the flow targets of that repository workspace? Is the build definition configured to accept changes into the repository workspace? |
It would help if we knew a little more about how your build process is set up, and how you are using your 2 streams. Here's some things I would look at: The stream history has the change in it before the build is submitted, and after the build the change is history is back to the previous history. And the change set is back in my outgoing tree. I have tested both flow targets, the workspace flow target is set to the stream and the stream flow target is set to the workspace. I am pretty sure this is a simple configuration issue. Just have not found any docs that are helpful yet. Still reading... A little more detail on the scenario. load a component into eclipse from the desired stream. Change the component checkin and deliver. All histories match at this point. All file repositories match at this point. Submit the build. Stream history goes back to previous while the workspace stream keeps the history as it was after the change. Open "Pending Change" and there is your code again, ready to be delivered. This is very puzzling and has crippled our development team. I also upgraded my RTC client to the lastest versoin 2.0.0.2 fp 3 A severity 1 PMR has been opened, I'll post the resutls here. |
It would help if we knew a little more about how your build process is set up, and how you are using your 2 streams. Here's some things I would look at: The stream history has the change in it before the build is submitted, and after the build the change is history is back to the previous history. And the change set is back in my outgoing tree. I have tested both flow targets, the workspace flow target is set to the stream and the stream flow target is set to the workspace. I am pretty sure this is a simple configuration issue. Just have not found any docs that are helpful yet. Still reading... A little more detail on the scenario. load a component into eclipse from the desired stream. Change the component checkin and deliver. All histories match at this point. All file repositories match at this point. Submit the build. Stream history goes back to previous while the workspace stream keeps the history as it was after the change. Open "Pending Change" and there is your code again, ready to be delivered. This is very puzzling and has crippled our development team. I also upgraded my RTC client to the lastest versoin 2.0.0.2 fp 3 A severity 1 PMR has been opened, I'll post the resutls here. Problem solved: Some misconfiguration on my part. I had my build def pointing to my stream instead of my workspace. I also had a flow target in my default component of my stream. I removed the target flow from the stream and changed the pointer in my build def and all is well. |
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.