Source control operation failed / Permission denied

You can ask dieng to transfer ownership of that workspace to you. Just
remember to transfer ownership back to dieng when you are done.

Cheers,
Geoff

scharffc wrote:

Hello

We are currently blocked in our project because I cannot solve the
problem below:

I have a

Permission denied during Source Control Operation

Permission denied only the owner of the repository workspace
GSD2009-test Stream Workspace 4 can modify it. Current owner is
cscharff and you are logged in as dieng.

Can someone explain me how to deal with the problem?

I am administrator as cscharff and do some test for the users with the
login dieng.

Thanks

Christelle

Hi Geoff,

That is a solution but is it standard solution?

We did not have that problem before and I do not know how it appeared.

Thanks

Christelle

You can ask dieng to transfer ownership of that workspace to you. Just
remember to transfer ownership back to dieng when you are done.

Cheers,
Geoff

scharffc wrote:

Hello

We are currently blocked in our project because I cannot solve the
problem below:

I have a

Permission denied during Source Control Operation

Permission denied only the owner of the repository workspace
GSD2009-test Stream Workspace 4 can modify it. Current owner is
cscharff and you are logged in as dieng.

Can someone explain me how to deal with the problem?

I am administrator as cscharff and do some test for the users with the
login dieng.

Thanks

Christelle

One possible explanation is that because permissions on workspaces were
tightened up in one of the releases, some things you used to be able to
do before are now under tighter control. So if you upgraded either your
client or servers, you would be seeing different behavior.

Cheers,
Geoff

scharffc wrote:

Hi Geoff,

That is a solution but is it standard solution?

We did not have that problem before and I do not know how it
appeared.

Thanks

Christelle

gmclemmwrote:
You can ask dieng to transfer ownership of that workspace to you.
Just
remember to transfer ownership back to dieng when you are done.

Cheers,
Geoff

scharffc wrote:
Hello

We are currently blocked in our project because I cannot solve the
problem below:

I have a

Permission denied during Source Control Operation

Permission denied only the owner of the repository workspace
GSD2009-test Stream Workspace 4 can modify it. Current owner is
cscharff and you are logged in as dieng.

Can someone explain me how to deal with the problem?

I am administrator as cscharff and do some test for the users with
the
login dieng.

Thanks

Christelle

Hello

We are using the latest version of RTC server / client. Do you have any further things I could investigate in permissions?

Christelle

One possible explanation is that because permissions on workspaces were
tightened up in one of the releases, some things you used to be able to
do before are now under tighter control. So if you upgraded either your
client or servers, you would be seeing different behavior.

Cheers,
Geoff

scharffc wrote:

Hi Geoff,

That is a solution but is it standard solution?

We did not have that problem before and I do not know how it
appeared.

Thanks

Christelle

gmclemmwrote:
You can ask dieng to transfer ownership of that workspace to you.
Just
remember to transfer ownership back to dieng when you are done.

Cheers,
Geoff

scharffc wrote:
Hello

We are currently blocked in our project because I cannot solve the
problem below:

I have a

Permission denied during Source Control Operation

Permission denied only the owner of the repository workspace
GSD2009-test Stream Workspace 4 can modify it. Current owner is
cscharff and you are logged in as dieng.

Can someone explain me how to deal with the problem?

I am administrator as cscharff and do some test for the users with
the
login dieng.

Thanks

Christelle

I'm not sure what you want to investigate. A workspace is intended for
use by a single individual (a stream is for shared use), so it is
working as designed. Or did I misunderstand your question?

Cheers,
Geoff

scharffc wrote:

Hello

We are using the latest version of RTC server / client. Do you have
any further things I could investigate in permissions?

Christelle

gmclemmwrote:
One possible explanation is that because permissions on workspaces
were
tightened up in one of the releases, some things you used to be able
to
do before are now under tighter control. So if you upgraded either
your
client or servers, you would be seeing different behavior.

Cheers,
Geoff

scharffc wrote:
Hi Geoff,

That is a solution but is it standard solution?

We did not have that problem before and I do not know how it
appeared.

Thanks

Christelle

gmclemmwrote:
You can ask dieng to transfer ownership of that workspace to you.
Just
remember to transfer ownership back to dieng when you are done.

Cheers,
Geoff

scharffc wrote:
Hello

We are currently blocked in our project because I cannot solve the
problem below:

I have a

Permission denied during Source Control Operation

Permission denied only the owner of the repository workspace
GSD2009-test Stream Workspace 4 can modify it. Current owner is
cscharff and you are logged in as dieng.

Can someone explain me how to deal with the problem?

I am administrator as cscharff and do some test for the users with
the
login dieng.

Thanks

Christelle

Ah! So when sharing the project we should share it in a stream?

Christelle

I'm not sure what you want to investigate. A workspace is intended for
use by a single individual (a stream is for shared use), so it is
working as designed. Or did I misunderstand your question?

Cheers,
Geoff

scharffc wrote:

Hello

We are using the latest version of RTC server / client. Do you have
any further things I could investigate in permissions?

Christelle

gmclemmwrote:
One possible explanation is that because permissions on workspaces
were
tightened up in one of the releases, some things you used to be able
to
do before are now under tighter control. So if you upgraded either
your
client or servers, you would be seeing different behavior.

Cheers,
Geoff

scharffc wrote:
Hi Geoff,

That is a solution but is it standard solution?

We did not have that problem before and I do not know how it
appeared.

Thanks

Christelle

gmclemmwrote:
You can ask dieng to transfer ownership of that workspace to you.
Just
remember to transfer ownership back to dieng when you are done.

Cheers,
Geoff

scharffc wrote:
Hello

We are currently blocked in our project because I cannot solve the
problem below:

I have a

Permission denied during Source Control Operation

Permission denied only the owner of the repository workspace
GSD2009-test Stream Workspace 4 can modify it. Current owner is
cscharff and you are logged in as dieng.

Can someone explain me how to deal with the problem?

I am administrator as cscharff and do some test for the users with
the
login dieng.

Thanks

Christelle

Yes, although you have to be a bit careful with the verb "share" ...
Eclipse uses that as the term for "put under version control". So you
would put an Eclipse project under version control with the Eclipse
"share" operation (which checks that Eclipse project into your RTC
repository workspace), and then you would share that checked-in Eclipse
project with other members of your team by "delivering" that workspace
to the stream (which will deliver that checked-in Eclipse workpace to
the stream).

Cheers,
Geoff

scharffc wrote:

Ah! So when sharing the project we should share it in a stream?

Christelle

gmclemmwrote:
I'm not sure what you want to investigate. A workspace is intended
for
use by a single individual (a stream is for shared use), so it is
working as designed. Or did I misunderstand your question?

Cheers,
Geoff

scharffc wrote:
Hello

We are using the latest version of RTC server / client. Do you have
any further things I could investigate in permissions?

Christelle

gmclemmwrote:
One possible explanation is that because permissions on workspaces
were
tightened up in one of the releases, some things you used to be
able
to
do before are now under tighter control. So if you upgraded either
your
client or servers, you would be seeing different behavior.

Cheers,
Geoff

scharffc wrote:
Hi Geoff,

That is a solution but is it standard solution?

We did not have that problem before and I do not know how it
appeared.

Thanks

Christelle

gmclemmwrote:
You can ask dieng to transfer ownership of that workspace to you.
Just
remember to transfer ownership back to dieng when you are done.

Cheers,
Geoff

scharffc wrote:
Hello

We are currently blocked in our project because I cannot solve the
problem below:

I have a

Permission denied during Source Control Operation

Permission denied only the owner of the repository workspace
GSD2009-test Stream Workspace 4 can modify it. Current owner is
cscharff and you are logged in as dieng.

Can someone explain me how to deal with the problem?

I am administrator as cscharff and do some test for the users with
the
login dieng.

Thanks

Christelle

I noticed a typo below. I meant to write "(which will deliver that
checked-in Eclipse project to the stream)".

Cheers,
Geoff

Geoffrey Clemm wrote:

Yes, although you have to be a bit careful with the verb "share" ...
Eclipse uses that as the term for "put under version control". So you
would put an Eclipse project under version control with the Eclipse
"share" operation (which checks that Eclipse project into your RTC
repository workspace), and then you would share that checked-in Eclipse
project with other members of your team by "delivering" that workspace
to the stream (which will deliver that checked-in Eclipse workpace to
the stream).

Cheers,
Geoff

scharffc wrote:
Ah! So when sharing the project we should share it in a stream?

Christelle

gmclemmwrote:
I'm not sure what you want to investigate. A workspace is intended
for
use by a single individual (a stream is for shared use), so it is
working as designed. Or did I misunderstand your question?

Cheers,
Geoff

scharffc wrote:
Hello

We are using the latest version of RTC server / client. Do you have
any further things I could investigate in permissions?

Christelle

gmclemmwrote:
One possible explanation is that because permissions on workspaces
were
tightened up in one of the releases, some things you used to be
able
to
do before are now under tighter control. So if you upgraded either
your
client or servers, you would be seeing different behavior.

Cheers,
Geoff

scharffc wrote:
Hi Geoff,

That is a solution but is it standard solution?

We did not have that problem before and I do not know how it
appeared.

Thanks

Christelle

gmclemmwrote:
You can ask dieng to transfer ownership of that workspace to you.
Just
remember to transfer ownership back to dieng when you are done.

Cheers,
Geoff

scharffc wrote:
Hello

We are currently blocked in our project because I cannot solve the
problem below:

I have a

Permission denied during Source Control Operation

Permission denied only the owner of the repository workspace
GSD2009-test Stream Workspace 4 can modify it. Current owner is
cscharff and you are logged in as dieng.

Can someone explain me how to deal with the problem?

I am administrator as cscharff and do some test for the users with
the
login dieng.

Thanks

Christelle

My team also spun our wheels this week trying to implement workspace collaboration as outlined in the RTC 2 help: http://publib.boulder.ibm.com/infocenter/rtc/v2r0m0/topic/com.ibm.team.scm.doc/topics/t_collaborating_with_another_workspace.html

We were attempting to do this as a simple way to funnell all changes from an external contributor through a full-time team member. So change sets from the external contributor's workspace would flow to a workspace of the full-time team member, and the team member would be responsible for reviewing them and delivering them to the stream.

But if the only solution for this is to transfer full ownership of workspaces around, that to me significantly diminishes the effectiveness of workspace collobration, and I would question the value of having flow targets that are other workspaces at all. If one has to have a real-time discussion with the owner of the target workspace to get something to flow, why bother with workspace ownership changes and the problems that could cause (forgetting to transfer back, people messing up eachother's workspaces, etc), why not just send them the changes?

So unless I'm missing something, I would think that recent "permission tightening" has severely crippled the workspace collobaration feature which is a documented feature in RTC. So just wondering if this really is all "working as designed" or not. Unless we missed it, we saw nothing in the help about needing to transfer workspace ownership.

Thanks...
Jeff

You should be using a stream as a flow target for this kind of
collaboration, not a workspace.

I've submitted work item 102159 to clarify in that help section that the
primary use of having a workspace as a flow target is to accept changes
from that workspace, not to deliver changes to it. If you want to have
multiple team members deliver to a shared configuration, that shared
configuration should be a stream, not a workspace.

WRT tightening up the permissions on a workspace, that was done to
prevent this kind of error (i.e. using a workspace when you should be
using a stream). In particular, a workspace is for a private
configuration for an individual, so having someone else update that
configuration out from underneath you would be disruptive. Also, a
workspace is commonly associated with a file area, so unless you owned
the workspace and its associated file area, you wouldn't have permission
to update the file area.

Cheers,
Geoff

turnham wrote:

My team also spun our wheels this week trying to implement workspace
collaboration as outlined in the RTC 2 help:
http://publib.boulder.ibm.com/infocenter/rtc/v2r0m0/topic/com.ibm.team.scm.doc/topics/t_collaborating_with_another_workspace.html

We were attempting to do this as a simple way to funnell all changes
from an external contributor through a full-time team member. So
change sets from the external contributor's workspace would flow to a
workspace of the full-time team member, and the team member would be
responsible for reviewing them and delivering them to the stream.

But if the only solution for this is to transfer full ownership of
workspaces around, that to me significantly diminishes the
effectiveness of workspace collobration, and I would question the
value of having flow targets that are other workspaces at all. If
one has to have a real-time discussion with the owner of the target
workspace to get something to flow, why bother with workspace
ownership changes and the problems that could cause (forgetting to
transfer back, people messing up eachother's workspaces, etc), why
not just send them the changes?

So unless I'm missing something, I would think that recent
"permission tightening" has severely crippled the workspace
collobaration feature which is a documented feature in RTC. So just
wondering if this really is all "working as designed" or
not. Unless we missed it, we saw nothing in the help about needing
to transfer workspace ownership.

Thanks...
Jeff