Hi Swat Oon,

this is possible. What you would do e.g. using the eclipse client:

1. Serach>Jazz Source Controls: Search for the repository workspaces owned by the user. You can open any of those and browse for their content.
2. On the Workspace Editor duplicate the workspace to get a workspace that is owned by you containing the data. You could load the repository workspace owned by the other user but it would be read only.
3. Load the workspace

Now you can work with the data and finally also deliver changes.

Thanks,

Ralph

Hi,

I think I came across this scenario in one of the articles/video:

Sharon worked on an enhancement which she kept in her repository workspace and did not deliver the changes to the stream. She then went on leave. Mark, her team mate was asked to deliver this enhancement during this period and hence had to access her repository workspace to get the enhancement changes.

Could you provide the steps to achieve that? Is there a way to do so without logging into the repository as Sharon?

Thanks loads.

Swat Oon

On 2011/01/20 19:53, swatoon wrote:

Sharon worked on an enhancement which she kept in her repository
workspace and did not deliver the changes to the stream. She then
went on leave. Mark, her team mate was asked to deliver this
enhancement during this period and hence had to access her repository
workspace to get the enhancement changes.

Could you provide the steps to achieve that? Is there a way to do so
without logging into the repository as Sharon?

I don't have the exact steps since I have never had to do that myself,
but I can talk about a couple things to watch out for.

If Sharon completed her change sets, then Mark can accept the change
sets into his repository workspace, do any merges or other necessary
cleanup, and then deliver Sharon's change sets to the appropriate
stream. If Sharon did not complete her change sets, then they can't be
accepted into Mark's repository workspace. Either someone will have to
log in as Sharon just long enough to complete the change sets, or the
changes will have to transferred to Mark's repository workspace as a
patch rather than by accepting them directly.

If Sharon's repository workspace is public, then Mark can look at her
workspace and search it and even load it. Nobody except Sharon can
change the repository workspace in any way, but people can see what's in
it. If Sharon's repository workspace is private, then Mark can't look
at it to see what change sets are in it. I think it is possible to get
at the change sets by other means, such as if they were attached to a
work item. They just can't be accepted directly from the workspace.

--
David Olsen
IBM Rational

Note that anyone who has read access to the component changed by Carol's
change sets can search for Carol's change sets (using the Search ->
Jazz_Source_Control -> Change_Sets operation), even if the change sets
only exist in Carol's private workspace (or for that matter, even if
they don't exist in any workspaces).

Cheers,
Geoff

On 1/21/2011 11:36 AM, David Olsen wrote:

On 2011/01/20 19:53, swatoon wrote:
Sharon worked on an enhancement which she kept in her repository
workspace and did not deliver the changes to the stream. She then
went on leave. Mark, her team mate was asked to deliver this
enhancement during this period and hence had to access her repository
workspace to get the enhancement changes.

Could you provide the steps to achieve that? Is there a way to do so
without logging into the repository as Sharon?

I don't have the exact steps since I have never had to do that myself,
but I can talk about a couple things to watch out for.

If Sharon completed her change sets, then Mark can accept the change
sets into his repository workspace, do any merges or other necessary
cleanup, and then deliver Sharon's change sets to the appropriate
stream. If Sharon did not complete her change sets, then they can't be
accepted into Mark's repository workspace. Either someone will have to
log in as Sharon just long enough to complete the change sets, or the
changes will have to transferred to Mark's repository workspace as a
patch rather than by accepting them directly.

If Sharon's repository workspace is public, then Mark can look at her
workspace and search it and even load it. Nobody except Sharon can
change the repository workspace in any way, but people can see what's in
it. If Sharon's repository workspace is private, then Mark can't look at
it to see what change sets are in it. I think it is possible to get at
the change sets by other means, such as if they were attached to a work
item. They just can't be accepted directly from the workspace.

--
David Olsen
IBM Rational