How to restrict users from delivering code in shared workspace
I have StreamA and StreamB > StreamB has shared componentA from StreamA.
FileA.java is present in StreamA>ComponentA and StreamB>ComponentA. FileA.java gives me a conflict when I switch the flow target of StreamB to StreamA (changes of StreamA flowing into StreamB). Now I want to notify the developer about this conflict. So I share this workspace with developerA. He searched for this shared workspace and loads it on his pending changes.
But I dont want that he resolves the conflict in the workspace that I shared with him. Is there a way that he sees my shared workspace in readonly mode? This will help him see the conflicts and deliver corrected code, but he should deliver it from his workspace.
This is very vital since there are many files and many developers involved in my project with more then 13 streams and flow targets to be switched daily.
Please let me know.
Accepted answer
A user cannot make changes to a repository workspace that is owned by another user.
Comments
I did a scoped based sharing of my workspace (so my scope was the project area). Now other developer who is also a member of the project area, was able to modify and deliver a change set from the shared workspace. Am I missing something?
The scope of a workspace should only determines who can read a workspace, and should not affect who can modify a workspace. If anyone other than an owner of a workspace can modify a workspace in your environment, please report this as a bug to IBM support.
1 vote
One other answer
Hi Pravin,
new ► repository workspace
give a name and type description (optional)
click next :)
select a repository (current or another)
click next :)
please read them carefully
select a scoped
i think it is your wish.
Comments
I did a scoped based sharing of my workspace (so my scope was the project area). Now other developer who is also a member of the project area, was able to modify and deliver a change set from the shared workspace. Am I missing something?
1 vote
Hi Pravin I think yes we missing something both. Your components have public read access. Our structure maybe help you for this issue..
Our Streams & components
Team A Streams (Visibility: Project Area, Owner: Team A)
Sample scenario 1:Team B Streams (Visibility: Project Area, Owner: Team B)X Comp (Visibility: Public, Owner: RTCADMIN)
Y Comp (Visibility: Public, Owner: RTCADMIN)
Z Comp (Visibility: Public, Owner: RTCADMIN)
T Comp (Visibility: Public, Owner: RTCADMIN)
We have 2 developers same team for example Team A.
Developer 1: Create new repo. ws. from Team A Stream and load X component
Developer 2: do same thing like developer 1
Dev1 create a change set for example he change sample.txt and deliver.
Dev2 look up the your pending changes and see dev1's change set in incoming changes. He must accept it. And dev2 create new change set for sample.txt and deliver.
Dev1 see it and accept like dev2.
Sample scenario 2:
Developer 1: Create new repo. ws. from Team A Stream and load X component
Developer 2: do same thing like developer 1
Dev1 create a change set for example he change sample.txt and deliver.
Dev2 look up the your pending changes and see dev1's change set in incoming changes. He must accept it. And dev2 create new change set for sample.txt and deliver.
Dev1 see it and accept like dev2.
Sample scenario 2:
Dev1 and Dev2 load same component and they working same time for same sample.txt.
Dev1 create his change set and deliver.
Dev2 create his change set and press deliver he have a warning from RTC SCM "This file have a conflict what are you doing bro?"
Dev1 create his change set and deliver.
Dev2 create his change set and press deliver he have a warning from RTC SCM "This file have a conflict what are you doing bro?"
Dev1 and Dev2 talks about that and they resolve confilct together. (people communication)
Sample scenario 3:
Dev1 and Dev2 load same comp. and they working same time for same sample.txt but different versions.
They deliver their change set another workspace (Dev3's WS). Dev3 role is versions manager or SCM admin or conflict expert or superman :) He resolve conflict or select a version or merge and deliver server.
Usually Dev3 = Dev1 + Dev2 it looks like scenario 2 but What is the difference? Diff. is shared WS.
We usually do not prefer load someone else's workspace. We prefer another workspace (shared ws). And we deliver server after resolving the problems.
We usually do not prefer load someone else's workspace. We prefer another workspace (shared ws). And we deliver server after resolving the problems.
1 vote
Thanks a lot for the details. This helps!