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

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.

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.