Loss of change sets in secondary stream
Hi everyone,
I'm new to Jazz platform and I'm practicing to educate myself on version control (Source Control Management).
I'm facing a problem with streams.
I created a secondary stream, which has the main stream as its flow target. As I deliver change sets to the secondary stream, they still visible via Jazz SCM and via Rhapsody. After I deliver the change sets from de secondary stream to the main stream, these change sets get lost.
I looks like the Jazz server show a reference to a change set that doesn't exist anymore.
I noticed that any change set delivered directly to the main stream stays visible, with no problem.
How can I fix this?
Thanks in advance,
Portolon
I'm new to Jazz platform and I'm practicing to educate myself on version control (Source Control Management).
I'm facing a problem with streams.
I created a secondary stream, which has the main stream as its flow target. As I deliver change sets to the secondary stream, they still visible via Jazz SCM and via Rhapsody. After I deliver the change sets from de secondary stream to the main stream, these change sets get lost.
I looks like the Jazz server show a reference to a change set that doesn't exist anymore.
I noticed that any change set delivered directly to the main stream stays visible, with no problem.
How can I fix this?
Thanks in advance,
Portolon
3 answers
I assume you are seeing this behavior in the Rhapsody client (not the RTC Eclipse client), correct?
If so, you would need to file a bug against the Rhapsody client.
On the other hand, if you can reproduce this bug using just the RTC Eclipse client, then you should file the bug against RTC.
If so, you would need to file a bug against the Rhapsody client.
On the other hand, if you can reproduce this bug using just the RTC Eclipse client, then you should file the bug against RTC.
Several points to mention here:
1. You usually flow changes between a stream and a repository workspace. If there are conflicting changes, you must use a repository workspace to resolve them. You can think of a stream as something similar to a branch - a specific configuration of content.
2. You can only deliver from one stream to another if there are no conflicting changes, in which case the changes end in the other stream.
The changes should not be lost. You should be able to see them in the history still. The description of what you do is not detailed enough to understand what could be happening. Consider reading
https://jazz.net/library/article/539
https://jazz.net/library/article/126
1. You usually flow changes between a stream and a repository workspace. If there are conflicting changes, you must use a repository workspace to resolve them. You can think of a stream as something similar to a branch - a specific configuration of content.
2. You can only deliver from one stream to another if there are no conflicting changes, in which case the changes end in the other stream.
The changes should not be lost. You should be able to see them in the history still. The description of what you do is not detailed enough to understand what could be happening. Consider reading
https://jazz.net/library/article/539
https://jazz.net/library/article/126
