It's all about the answers!

Ask a question

mysterious links between change sets in different workspaces


Ulrich Eckhardt (23612223) | asked Sep 30 '11, 7:10 a.m.
Following procedure should demonstrate the problem:

    Create two equal workspaces WS1 and WS2
    Set WS1 as flow target for WS2
    Load component X into both workspaces
    Make a change to component X in WS1
    Create a changeset CS from the change in WS1
    Note: CS now automatically shows up as incoming in WS2
    Accept CS in WS2
    Note: there are no pending changes in WS2
    Note: CS is still shown as outgoing in WS1
    Suspend CS in WS1
    Note: CS now shows up as suspended in WS1


The interesting thing here is that in WS2, CS is shown as both outgoing (which still makes some sense to me, since the change set is active in WS2 but not in its flow target WS1) but also as suspended. However, the changes to the files are not suspended in WS2, they are active in the sandbox!

Some further testing seems to reveal that when I suspend the changeset in one workspace, it is automatically suspended in the other workspace, too. When resuming it in one workspace, it is automatically resumed in the other workspace, as if they were linked in some way. I haven't verified all possible combinations of this, but the above already shows that "suspended" doesn't mean that the changes are not present in the sandbox, which is somehow completely against the idea of suspending things.

Can anyone explain this?

Uli

4 answers



permanent link
Tim Mok (6.6k38) | answered Oct 04 '11, 10:37 a.m.
JAZZ DEVELOPER
Sorry, I was confused about your example saying that changes were made in WS1. My post meant that suspended changes will show in the suspended list for all workspaces. It helps when changes are suspended from the workspace where you do all your changes. I think that would be WS2 in your case. When you are no longer working on the change set, suspend it in WS2. If you had delivered it to WS1 and suspend it there then it shows as outgoing for WS2 flowing to WS1.

You can always choose to discard from WS1 instead of suspending. Then only suspend in the context of WS2. If WS1 needs the change set again, you deliver it from WS2. That's what I do when flowing to another of my workspaces that is used as a staging area. I also never make changes in WS1 because it breaks my idea of using it as a buffer to the stream and makes you want to suspend in WS1.

permanent link
Ulrich Eckhardt (23612223) | answered Oct 04 '11, 3:19 a.m.
This sounds odd when you accept into WS2 yet it still shows as outgoing in WS1. You didn't mention WS2's flow target but it sounds like it is flowing to WS1 and WS1 is flowing to WS2.


WS1's flow target is a stream, WS2's is WS1. I'm using this two-staged approach to decouple me from incoming changes and to decouple others from my outgoing changes, both of which I test first in WS1.


Did you try refreshing Pending Changes? If there is still a problem, open a work item against Source Control/Client/Eclipse UI. Please include screenshots of your Pending Changes in the work item as well.


https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=38642 actually describes the issue pretty well. It also presents a pretty clear attitude: "We do not intend to address this.", quoting John Camelon.


For the suspended, it shows all of your suspended change sets even if it is in your workspace. This allows you to suspend in one workspace and resume in another. It is useful because you should load a workspace only once to avoid out of sync issues.


I'm sorry, I don't understand this statement of yours. In any case, the changes are only actually removed from one workspace. They are still present in the other workspace, even though they show up as suspended there, and it's impossible to tell which one except by looking at the files.

Just in case you confused that, I did not load a workspace multiple times, I created two workspaces!

Uli

permanent link
Tim Mok (6.6k38) | answered Sep 30 '11, 9:42 a.m.
JAZZ DEVELOPER
Following procedure should demonstrate the problem:

    Create two equal workspaces WS1 and WS2
    Set WS1 as flow target for WS2
    Load component X into both workspaces
    Make a change to component X in WS1
    Create a changeset CS from the change in WS1
    Note: CS now automatically shows up as incoming in WS2
    Accept CS in WS2
    Note: there are no pending changes in WS2
    Note: CS is still shown as outgoing in WS1
    Suspend CS in WS1
    Note: CS now shows up as suspended in WS1


The interesting thing here is that in WS2, CS is shown as both outgoing (which still makes some sense to me, since the change set is active in WS2 but not in its flow target WS1) but also as suspended. However, the changes to the files are not suspended in WS2, they are active in the sandbox!

Some further testing seems to reveal that when I suspend the changeset in one workspace, it is automatically suspended in the other workspace, too. When resuming it in one workspace, it is automatically resumed in the other workspace, as if they were linked in some way. I haven't verified all possible combinations of this, but the above already shows that "suspended" doesn't mean that the changes are not present in the sandbox, which is somehow completely against the idea of suspending things.

Can anyone explain this?

Uli
This sounds odd when you accept into WS2 yet it still shows as outgoing in WS1. You didn't mention WS2's flow target but it sounds like it is flowing to WS1 and WS1 is flowing to WS2. Did you try refreshing Pending Changes? If there is still a problem, open a work item against Source Control/Client/Eclipse UI. Please include screenshots of your Pending Changes in the work item as well.

For the suspended, it shows all of your suspended change sets even if it is in your workspace. This allows you to suspend in one workspace and resume in another. It is useful because you should load a workspace only once to avoid out of sync issues.

permanent link
Geoffrey Clemm (30.1k33035) | answered Sep 30 '11, 9:22 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, your observations and conclusions are all correct.
The suspended set is global ... i.e. there is a single suspended set for
a given user, that shows up on all of their workspaces.
Because of this, the presence of a change-set in the suspended set is
unrelated to whether or not that change-set is in your workspace.

There is a workitem requesting that each workspace have its own
suspended set: 101009. Please feel free to add a comment to that work
item, indicating your interest/support.

Cheers,
Geoff

On 9/30/2011 7:38 AM, ulricheckhardt wrote:
Following procedure should demonstrate the problem:

Create two equal workspaces WS1 and WS2
Set WS1 as flow target for WS2
Load component X into both workspaces
Make a change to component X in WS1
Create a changeset CS from the change in WS1
Note: CS now automatically shows up as incoming in
WS2
Accept CS in WS2
Note: there are no pending changes in
WS2

Note: CS is still shown as outgoing in
WS1

Suspend CS in WS1
Note: CS now shows up as suspended in
WS1



The interesting thing here is that in WS2, CS is shown as both
outgoing (which still makes some sense to me, since the change set is
active in WS2 but not in its flow target WS1) but also as suspended.
However, the changes to the files are
not suspended in WS2, they are active in
the sandbox!

Some further testing seems to reveal that when I suspend the changeset
in one workspace, it is automatically suspended in the other
workspace, too. When resuming it in one workspace, it is
automatically resumed in the other workspace, as if they were linked
in some way. I haven't verified all possible combinations of this,
but the above already shows that "suspended" doesn't mean
that the changes are not present in the sandbox, which is somehow
completely against the idea of suspending things.

Can anyone explain this?

Uli

Your answer


Register or to post your answer.