Currently, a suspended change set is logically linked to the user that
suspended the change set, rather than the workspace that suspended the
change set. Then the suspended change sets of a given user will show up
in the suspended set of any workspace owned by that user.

This is done so that you don't lose track of some of your suspended
change sets when you delete a workspace (you have to explicitly drop a
suspended change set in order for it to no longer appear on those lists).

But I do agree that this is not the behavior I'd like to see. I'd want
the suspected change-set to be tied to the workspace it was suspended
from, since in my case, that change-set is only relevant in the context
of that workspace, and just give me a warning if I've asked to delete a
workspace that has suspended change sets.

I've submitted work item 101009 for this. Please feel free to register
your interest in this work item by subscribing or commenting on it.

Cheers,
Geoff



JanVdP wrote:

Imagine the following setup:

1 component: "comp"

2 streams: S1 and S2, both with component "comp"

2 Repository workspaces W1 and W2 respectively linked to S1 and S2.

While working in W1, I receive a message to start working on something
else, so I suspend my current changes. This is where the unexpected
behaviour occurs. The suspended changes show up in both the W1 as
well as W2 repository workspaces...

Could this be a bug?

Thanks!
Jan

Personally, I use this functionality as a feature. I develop both in Linux
and Windows and need to test my new code in each. I have a different
Repository Workspace for each environment and I keep them both up to date
relative to the stream.

To test my work-in-progress, I suspend my changeset from one workspace and
resume it in the other. That lets me get my changes without having to
close the changeset. Alternatively I could have closed the change set and
built on top of it, but sometimes I rather not because there might be many
times going back and forth between Windows/Linux to get it right. So I can
continue putting my work in the same active changeset because too many
'not-quite-right' changesets gets noisy when I deliver.


On Fri, 04 Dec 2009 10:15:12 -0500, Geoffrey Clemm
<geoffrey> wrote:

Currently, a suspended change set is logically linked to the user that
suspended the change set, rather than the workspace that suspended the
change set. Then the suspended change sets of a given user will show up
in the suspended set of any workspace owned by that user.

This is done so that you don't lose track of some of your suspended
change sets when you delete a workspace (you have to explicitly drop a
suspended change set in order for it to no longer appear on those lists).

But I do agree that this is not the behavior I'd like to see. I'd want
the suspected change-set to be tied to the workspace it was suspended
from, since in my case, that change-set is only relevant in the context
of that workspace, and just give me a warning if I've asked to delete a
workspace that has suspended change sets.

I've submitted work item 101009 for this. Please feel free to register
your interest in this work item by subscribing or commenting on it.

Cheers,
Geoff



JanVdP wrote:
Imagine the following setup:
1 component: "comp"
2 streams: S1 and S2, both with component "comp"
2 Repository workspaces W1 and W2 respectively linked to S1 and S2.
While working in W1, I receive a message to start working on something
else, so I suspend my current changes. This is where the unexpected
behaviour occurs. The suspended changes show up in both the W1 as
well as W2 repository workspaces...
Could this be a bug?
Thanks!
Jan

--

Note: For folks interested in this thread, a discussion has been
occurring in work item 101009. Quoting from my most recent comment there:

-----
Note that the suggestion in comment 2 is not to deliver the suspended
change set to the other workspace, but rather to provide the operation
requested in work item 36080, which delivers it to the *suspended* set
of the other workspace, and so does not cause it to be open in 2
workspaces (or any workspaces).

I believe the difference of opinion on this issue reflect whether or not
one works on just a single project (in which case one just has somewhat
different flavors of workspaces on the same basic configuration) or
whether one works in parallel in multiple projects, and having suspended
change-sets incorrectly flow from one workspace to another is a problem.

But it sounds like a generally acceptable compromise would be to use the
approach suggested in comment 1, where the system makes available in a
workspace all change sets suspended by the user, but in the GUI, it
clearly separates change sets suspended from *this* workspace, from
change sets suspended from *other* workspaces.
-----

Cheers,
Geoff

Andrew Hoo wrote:

Personally, I use this functionality as a feature. I develop both in
Linux and Windows and need to test my new code in each. I have a
different Repository Workspace for each environment and I keep them both
up to date relative to the stream.

To test my work-in-progress, I suspend my changeset from one workspace
and resume it in the other. That lets me get my changes without having
to close the changeset. Alternatively I could have closed the change set
and built on top of it, but sometimes I rather not because there might
be many times going back and forth between Windows/Linux to get it
right. So I can continue putting my work in the same active changeset
because too many 'not-quite-right' changesets gets noisy when I deliver.


On Fri, 04 Dec 2009 10:15:12 -0500, Geoffrey Clemm
geoffrey.clemm@us.ibm.com> wrote:

Currently, a suspended change set is logically linked to the user that
suspended the change set, rather than the workspace that suspended the
change set. Then the suspended change sets of a given user will show
up in the suspended set of any workspace owned by that user.

This is done so that you don't lose track of some of your suspended
change sets when you delete a workspace (you have to explicitly drop a
suspended change set in order for it to no longer appear on those lists).

But I do agree that this is not the behavior I'd like to see. I'd
want the suspected change-set to be tied to the workspace it was
suspended from, since in my case, that change-set is only relevant in
the context of that workspace, and just give me a warning if I've
asked to delete a workspace that has suspended change sets.

I've submitted work item 101009 for this. Please feel free to
register your interest in this work item by subscribing or commenting
on it.

Cheers,
Geoff



JanVdP wrote:
Imagine the following setup:
1 component: "comp"
2 streams: S1 and S2, both with component "comp"
2 Repository workspaces W1 and W2 respectively linked to S1 and S2.
While working in W1, I receive a message to start working on something
else, so I suspend my current changes. This is where the unexpected
behaviour occurs. The suspended changes show up in both the W1 as
well as W2 repository workspaces...
Could this be a bug?
Thanks!
Jan