It's all about the answers!

Ask a question

non-modifiable components in stream


David Sedlock (16122012) | asked Aug 11 '09, 8:36 a.m.
We need to be able to make components non-modifiable on a stream-by-stream basis. This is important for us so that we can stick to a "mainline discipline" in the component development (component is reused in many streams, but modifiable in only one).

non-modifiable is perhaps a little overstated. It is ok for a component to be modified in a workspace, as long as the changes go nowhere. So: no change sets, no baselines, no deliver; if the developer accepts an incoming baseline, his changes are overwritten.

The functionality here would be the same as the UCM project policy that allows you to mark components non-modifiable, which doesn't prevent anyone from modifying the files in a shapshot view. (In a dynamic view checkout is prevented.)

-David

4 answers



permanent link
Andrew Hoo (1.0k1) | answered Aug 11 '09, 10:10 a.m.
JAZZ DEVELOPER
I think you can adapt http://jazz.net/library/article/215#componentadvisor
to fit your process.

On Tue, 11 Aug 2009 08:38:02 -0400, David.Sedlock.infineon.com
<David> wrote:

We need to be able to make components non-modifiable on a
stream-by-stream basis. This is important for us so that we can stick
to a "mainline discipline" in the component development
(component is reused in many streams, but modifiable in only one).

non-modifiable is perhaps a little overstated. It is ok for a
component to be modified in a workspace, as long as the changes go
nowhere. So: no change sets, no baselines, no deliver; if the
developer accepts an incoming baseline, his changes are overwritten.

The functionality here would be the same as the UCM project policy
that allows you to mark components non-modifiable, which doesn't
prevent anyone from modifying the files in a shapshot view. (In a
dynamic view checkout is prevented.)

-David



--

permanent link
David Sedlock (16122012) | answered Aug 14 '09, 4:32 a.m.
Andrew, the article you refer to gives me a lot of food for thought, but I did not find an obvious way to say, simply, "no changes can be delivered to this component in this stream by anyone in any circumstances". I tend to think that a simple flag in the stream is the right way to provide this.

permanent link
Geoffrey Clemm (30.1k33035) | answered Aug 14 '09, 9:33 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I agree that there is no simple way to specify what you want here, so
I've submitted work item 90157 to ask that there be one.

If you carefully step through the steps described in the article, you
will be able to achieve what you want. In particular, I believe if you
familiarize yourself with the following steps, the rest is reasonably
intuitive:

# In the Team Area editor (for the team area that owns the stream to be
controlled), expand the Process Customization section and press the
Customize the process link.
# In the Customization list on the left, select the Operation Behavior
item. The right half of the editor will update with a tables of roles
and operation behaviour.
# Select the cell for Source Control / Deliver (server) under the
Everyone column.
# Enable the Preconditions and follow-up actions are configured for this
operation checkbox.
# Under Preconditions press the Add button.
# In the dialog select the Restrict Change set delivery to components in
a stream precondition. Press Ok.
# In the Restriction Details table of components, select all the
components and press Edit Permissions.

Cheers,
Geoff

David.Sedlock.infineon.com wrote:
Andrew, the article you refer to gives me a lot of food for thought,
but I did not find an obvious way to say, simply, "no changes
can be delivered to this component in this stream by anyone in any
circumstances". I tend to think that a simple flag in the stream
is the right way to provide this.

permanent link
Andrew Hoo (1.0k1) | answered Aug 14 '09, 9:37 a.m.
JAZZ DEVELOPER
Yeah, reading back on the article, there is alot of stuff in it because
its trying to cover all bases from a tutorial startpoint that everybody
can follow.

We try not to shove too many options in your face in the stream editor
especially if they're unlikely to be changed (also, not everybody can
change the process operation behaviour so we're exposing alot of stuff to
people who simply don't care).

For you, I think all you need to do is setup the process on 'everybody',
but then not check any roles in the dialog. (and you can forget about
having users own components completely). Hopefully you only need to do
this once and then you can forget about it; but let us know if the setup
cost and that UI workflow is still to high.

But you're right, there is no 'simple' way. Feel free to open an
enhancement... maybe a checkbox style in the stream editor that sets up
this backing process model for you.



On Fri, 14 Aug 2009 04:38:04 -0400, David.Sedlock.infineon.com
<David> wrote:

Andrew, the article you refer to gives me a lot of food for thought,
but I did not find an obvious way to say, simply, "no changes
can be delivered to this component in this stream by anyone in any
circumstances". I tend to think that a simple flag in the stream
is the right way to provide this.



--

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.