Read-only components and baselines organizations

vtrebuchon wrote:

I have two simple (?) requests about 'best practices' in Rational Team
Concert around components and baselines :

1. What is the (best) way to provide a team/stream in a RTC project
with a component as 'read-only' ?

Into the same project area, assuming we have a team A responsible for
the development of component A and a team B for component B, the
question is how can I define that the stream for team A can modify
the component A and only 'see' the component B ?

I'm aware of the following information :
http://jazz.net/library/article/215#protect_some
but this is more around 'visibility' of components, rather than access
permissions ...

WRT components, "visibility" and "read access" are the same, so article
215 is what defines what you can do to make a component read-only for a
particular stream.

This also has been requested in work item 63844
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=63844

There is currently no support for folder-level control access control,
such as is requested in work item 63844.

2. What is the best way to enforce that projects have to start working
based on a set of baselines ?

What did you have in mind by "enforce". When you create a stream, you
can initialize it with a specific set of baselines, just as you do with
ClearCase UCM. Unlike ClearCase UCM, you can change the configuration
of a stream at any time to be any configuration (assuming you are
authorized to modify that stream), so the configuration you started a
stream with doesn't constrain the future configurations of that stream.

The question is about how to best manage that specific baselines have
been created by specific projects ... In RTC, if you look at the
component baselines, you get a complete list of ALL baselines (that
you can filter by stream, if I remember well) ... but it's not easy
to get the information based on project and/or project timelines ...

In RTC, you would normally initialize a stream with a "snapshot" (which
is a consistent set of baselines). To see the snapshots associated with
a stream, select that stream in the team artifact navigator, and select
the "Show -> Snapshots" operation.

For those who know baselines/projects in UCM, I'd like to easily
manage that a new project starts to work based on a particular
baseline from a previous project (timeline) ...

Just create a stream in that project area, and initialize that stream to
have the desired snapshot.

Cheers,
Geoff

Thanks for your answers, Geoff

Just one detail around the 'visibility' and 'read/write' permission :
If some teams need to load some components from their streams into some repository/local workspaces (in order to compile) but HAVE to not deliver any change on these components back into the stream, how do they do that ? (I might not have understood correctly the article #215)

Thanks for your help
Vincent

vtrebuchon wrote:

I have two simple (?) requests about 'best practices' in Rational Team
Concert around components and baselines :

1. What is the (best) way to provide a team/stream in a RTC project
with a component as 'read-only' ?

Into the same project area, assuming we have a team A responsible for
the development of component A and a team B for component B, the
question is how can I define that the stream for team A can modify
the component A and only 'see' the component B ?

I'm aware of the following information :
http://jazz.net/library/article/215#protect_some
but this is more around 'visibility' of components, rather than access
permissions ...

WRT components, "visibility" and "read access" are the same, so article
215 is what defines what you can do to make a component read-only for a
particular stream.

This also has been requested in work item 63844
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=63844

There is currently no support for folder-level control access control,
such as is requested in work item 63844.

2. What is the best way to enforce that projects have to start working
based on a set of baselines ?

What did you have in mind by "enforce". When you create a stream, you
can initialize it with a specific set of baselines, just as you do with
ClearCase UCM. Unlike ClearCase UCM, you can change the configuration
of a stream at any time to be any configuration (assuming you are
authorized to modify that stream), so the configuration you started a
stream with doesn't constrain the future configurations of that stream.

The question is about how to best manage that specific baselines have
been created by specific projects ... In RTC, if you look at the
component baselines, you get a complete list of ALL baselines (that
you can filter by stream, if I remember well) ... but it's not easy
to get the information based on project and/or project timelines ...

In RTC, you would normally initialize a stream with a "snapshot" (which
is a consistent set of baselines). To see the snapshots associated with
a stream, select that stream in the team artifact navigator, and select
the "Show -> Snapshots" operation.

For those who know baselines/projects in UCM, I'd like to easily
manage that a new project starts to work based on a particular
baseline from a previous project (timeline) ...

Just create a stream in that project area, and initialize that stream to
have the desired snapshot.

Cheers,
Geoff

Article 215 has two sections. The first section is on "read protection
scenarios", so that says how to arrange for whether or not a user has
read access to a given component. The second section is on "write
protection scenarios". That is the section which tells you how to
control which users are allowed to deliver changes to a component back
to the stream. In particular, the section titled "Use permissions to
control delivery to components" would be the one you'd want to read over.

Cheers,
Geoff

vtrebuchon wrote:

Thanks for your answers, Geoff

Just one detail around the 'visibility' and 'read/write' permission :
If some teams need to load some components from their streams into
some repository/local workspaces (in order to compile) but HAVE to
not deliver any change on these components back into the stream, how
do they do that ? (I might not have understood correctly the article
#215)

Thanks for your help
Vincent

gmclemmwrote:
vtrebuchon wrote:
I have two simple (?) requests about 'best practices' in Rational
Team
Concert around components and baselines :

1. What is the (best) way to provide a team/stream in a RTC project
with a component as 'read-only' ?

Into the same project area, assuming we have a team A responsible
for
the development of component A and a team B for component B, the
question is how can I define that the stream for team A can modify
the component A and only 'see' the component B ?

I'm aware of the following information :
http://jazz.net/library/article/215#protect_some
but this is more around 'visibility' of components, rather than
access
permissions ...

WRT components, "visibility" and "read access" are
the same, so article
215 is what defines what you can do to make a component read-only for
a
particular stream.

This also has been requested in work item 63844

https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=63844
There is currently no support for folder-level control access control,

such as is requested in work item 63844.

2. What is the best way to enforce that projects have to start
working
based on a set of baselines ?

What did you have in mind by "enforce". When you create a
stream, you
can initialize it with a specific set of baselines, just as you do
with
ClearCase UCM. Unlike ClearCase UCM, you can change the configuration

of a stream at any time to be any configuration (assuming you are
authorized to modify that stream), so the configuration you started a

stream with doesn't constrain the future configurations of that
stream.

The question is about how to best manage that specific baselines
have
been created by specific projects ... In RTC, if you look at the
component baselines, you get a complete list of ALL baselines (that
you can filter by stream, if I remember well) ... but it's not easy
to get the information based on project and/or project timelines
...
In RTC, you would normally initialize a stream with a
"snapshot" (which
is a consistent set of baselines). To see the snapshots associated
with
a stream, select that stream in the team artifact navigator, and
select
the "Show -> Snapshots" operation.

For those who know baselines/projects in UCM, I'd like to easily
manage that a new project starts to work based on a particular
baseline from a previous project (timeline) ...

Just create a stream in that project area, and initialize that stream
to
have the desired snapshot.

Cheers,
Geoff

Hi,
I'm trying to create infrastructure components which will be writable in one project and read-only in anther project.
I've gone over the entire post and article 215 and it doesn't work for me.

I've created to project areas (Proj A and Proj B) on the server, and the relevant components in each of them. I want that all the components in Proj B will be part of Proj A as read-only.

The owner of the components in Proj B is Proj B. I added the components from Proj B to the relevant stream in Proj A. However, I was still able to change files which belong to Proj B from Proj A repository WS (I work with integration to Visual Studio)

Is there anything else I should do to make this work?

Thanks!
Lilach

Hello,

things have changed in RTC 3.0 since I've posted this topic (this was RTC 2.x) ...
You can now allow (or not) teams and/or roles to deliver changes on components in streams : you have to define operation behaviour for deliver (server side) operation in the process configuration of your process (open process configuration - team configuration - operation behavior - choose Source Control - Deliver (Server) - The precondition to add is named 'Restrict Change set delivery to components in a stream')

Still it does not 'protect' one project/team to modify one component in its own stream/repo workspace,but the idea is you can setup environments for projects where you allow team(s) to modify (e.g. deliver changes) components into some specific streams and to forbid the same team(s) to deliver changes into some other components ...

I did not check all combinaisons (projects/teams/roles permissions for projects/streams/repo workspaces) but it works fine to define that each team has its own stream to modify its own component and cannot modify other components in the same stream.

Hope this helps

Hi,
I'm trying to create infrastructure components which will be writable in one project and read-only in anther project.
I've gone over the entire post and article 215 and it doesn't work for me.

I've created to project areas (Proj A and Proj B) on the server, and the relevant components in each of them. I want that all the components in Proj B will be part of Proj A as read-only.

The owner of the components in Proj B is Proj B. I added the components from Proj B to the relevant stream in Proj A. However, I was still able to change files which belong to Proj B from Proj A repository WS (I work with integration to Visual Studio)

Is there anything else I should do to make this work?

Thanks!
Lilach

Hi,
Thanks for the update.
Is there a way to block changes on a component? Deliver is to far in the process.
What I actually want to do is to prevent the edit process of files on a read-only component.