It's all about the answers!

Ask a question

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


Karthik Krishnan (8898122164) | asked Sep 13 '13, 9:22 a.m.
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?

2 answers



permanent link
Geoffrey Clemm (30.1k33035) | answered Sep 13 '13, 10:55 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.

Comments
Karthik Krishnan commented 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 commented Sep 16 '13, 4:03 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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 commented Sep 17 '13, 3:41 a.m.

Thanks Geoff. Will do a test and report feedback


permanent link
Martha Toribio (611) | answered 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

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.