https://stackoverflow.com/questions/17515809
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianWhen you create a repo workspace, you can select "project scoped" in order for the member of the project area to be able to have a look at your change sets that you have checked out in it.
That means they will be able to add your repo workspace to the "flow target" section of their own repo workspace, not for delivering anything (you cannot push change sets to a repo workspace you don't own), but to accept change sets.
This is very useful if you check in changes, ... but don't deliver them on the stream.
If the visibility is "private", your change sets are stuck in your repo workspace.
If the visibility is "project scoped", another member of the project area can have a look, accept your changes and deliver them for you while you are not available.
The article "Controlling access to source control in Rational Team Control" adds more on the "project scoped" visibility, for other elements than just the "repo workspace".
For instance, a component can have its visibility scoped:
The access control for source control is based upon the component.
- For components owned by the project area, its access is scoped the same way the project area is.
- For components owned by an individual user, the owner can specify how it is scoped.
For streams:
Starting with RTC 3.0.1, streams can be scoped to individual team areas, meaning that only the team's members will have access to the streams and components that the team owns.
- Pros:
- Tighter access control.
- Access control can follow organizational hierarchy.
- Cons:
- Not all teams fit cleanly onto an org-chart.
