Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

is it possible to set a restriction to accept all incoming changes before delivery?

Questions
Tags
Users
Badges
Karthik Krishnan
(889●9●123●165) edited
Sep 13 '13, 9:46 a.m.
 Is it possible to set a restriction (out of the box) in RTC to accept all the incoming changesets in workspace before delivering the changesets?

In other words force developer to accept before delivering the change sets

Also what is the user of this precondition "Require workspace to be caught up before 
delivering"?

Edit: I read about "Require workspace to be caught up before delivering" and it looks like this will solve my use case but what about changing flow targets? In the case of changing flow target, i don't to accept or deliver all changes intentionally. How can this be achieved in the scenario?

0 votes

2 answers
5,745 views
0 votes

2 answers

Permanent link
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (30.1k●3●30●35) Sep 13 '13, 10:55 p.m.
Yes, "require workspace to be caught up before delivering" is the precondition you would turn on for a stream if you want to require that the user accept all incoming change-sets from that stream before delivering to that stream.
How you have set your flow targets is not relevant to this question.   In particular, changing your flow target does not cause any change sets to be accepted from (or delivered to) either the old or the new flow target.

3 votes

Comments
Karthik Krishnan
Sep 16 '13, 4:40 a.m.

 Thanks Geoff for your answer.

What happens if the user changes the flow target in the workspace?
Scenario:
1. Stream A <-> Workspace A (Regular scenario)
2. Workspace A -> Stream B (Where the user needs to deliver his (one or few) changesets to a variant Stream)
During this setup 2, how will  "require workspace to be caught up before delivering"  work? Will it ask the user to accept the change sets from Stream B as this not a wanted behavior

How will this trigger work for this case? any pointers?

Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 16 '13, 4:03 p.m.

First, note that the "require workspace to be caught up before delivery to a stream" precondition is controlled by the stream.  So Stream A and Stream B get to decide independently whether they want to require a workspace be caught up before it can deliver to that stream.  So if you want to require a developer be caught up to all incoming changes from Stream A before delivering to Stream A, but do not want to require that they be caught up to all incoming changes from Stream B before delivering to Stream B, set this precondition on Stream A but not on Stream B.   Note:  Something you cannot do with this precondition is require that a developer be caught up with all changes on Stream A before delivering to Stream B.

Karthik Krishnan
Sep 17 '13, 3:41 a.m.

Thanks Geoff. Will do a test and report feedback

Permanent link
Martha Toribio
(6●1●1) Jan 24 '14, 1:57 p.m.
Hi Geoffrey,

I have a question about this. I have a workspace connected to stream D (development), and stream D is connected to stream T (trunk). This flow is made in order to have the developer continously updated to the latest trunk changes.
Ok, when there are incoming changes from stream T to the stream D, this means incoming to the stream, not the workspace, I need the mentioned precondition to work at this level but apparently cannot see whats incoming to the stream.
Is there any way to control this? prevent delivers to the stream D when this stream (not the workspace) has incoming changes?

Thanks

0 votes

Your answer

Register or log in 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 1,201
× 149

Question asked: Sep 13 '13, 9:22 a.m.

Question was seen: 5,745 times

Last updated: Jan 24 '14, 1:57 p.m.

Confirmation Cancel Confirm