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

Accept only baselines from a stream (not change sets)

We would like developer to deliver change sets to a stream and allow only baselines to be accepted from the stream, not individual change sets.

Why? After the deliver, a (stream) build is started. When it succeeds a baseline is created and developer may accept the baseline, but when it fails the baseline is not created and developers should not accept the change sets (because it inflicts their workspace with a failing build).

Alternative scenario would be that developers deliver to stream "A" where it is built, then automatically deliver a baseline from the (successful) build to a stream "B" and developer accept baselines from stream "B". This would imply a 'deliver target' to stream "A" and a 'accept target' (better: 'accept source') from stream "B". Is this possible?


I understand that the principle for "accept before deliver" is to assure that any merge conflicts are resolved in the developer's workspace. So there is a point in forcing developers to accept changes that cause conflicts.

Why not just accept the changes from the stream before delivery to the stream, you may wonder?

Suppose a build runs 4 hours. Joe and Mary start their private build at around 8am and find it to finish successful at 2pm. Joe delivers and May tries to deliver... oops. She has to accept Joe's changes first. Then she rebuilds and finishes at 6pm: time to go home, one day lost. Tom has worked late and managed to deliver at 8pm. Next day, Mary retries her delivery and finds that she needs to accept Tom's changes first, run a build and hopefully she can deliver that same day - possibly not when someone else beat her with a delivery.
So, people start to accept and deliver to the stream without checking their build. And when the build (on the stream) fails, all workspaces are infected with changes that fail the build, and nobody is able to build & test anymore.

0 votes


Accepted answer

Permanent link
Unfortunately, you cannot yet declare that a given flow target should
only be a source or only be a target. This is work item 12763. Please
feel free to add a comment to that work item to indicate your
interest/support.

Cheers,
Geoff


On 11/30/2011 2:38 AM, fschop wrote:
We would like developer to deliver change sets to a
stream and allow only baselines to be accepted from the stream, not
individual change sets.

Why? After the deliver, a (stream) build
is started. When it succeeds a baseline is created and developer may
accept the baseline, but when it fails the baseline is not created
and developers should not accept the change sets (because it inflicts
their workspace with a failing build).

Alternative scenario would be that developers deliver to stream
"A" where it is built, then automatically deliver a
baseline from the (successful) build to a stream "B" and
developer accept baselines from stream "B". This would
imply a 'deliver target' to stream "A" and a 'accept
target' (better: 'accept source') from stream "B". Is this
possible?


I understand that the principle for "accept before deliver"
is to assure that any merge conflicts are resolved in the developer's
workspace. So there is a point in forcing developers to accept changes
that cause conflicts.

Why not just accept the changes from the stream before
delivery to the stream, you may wonder?

Suppose a build runs 4 hours. Joe and Mary start their private build
at around 8am and find it to finish successful at 2pm. Joe delivers
and May tries to deliver... oops. She has to accept Joe's changes
first. Then she rebuilds and finishes at 6pm: time to go home, one
day lost. Tom has worked late and managed to deliver at 8pm. Next
day, Mary retries her delivery and finds that she needs to accept
Tom's changes first, run a build and hopefully she can deliver that
same day - possibly not when someone else beat her with a delivery.
So, people start to accept and deliver to the stream without checking
their build. And when the build (on the stream) fails, all workspaces
are infected with changes that fail the build, and nobody is able to
build& test anymore.
Frank Schophuizen selected this answer as the correct answer

0 votes


2 other answers

Permanent link
I am not aware that this is possible. Today RTC is designed to allow accepting changes as frequent as possible and requested by the user to minimize conflicts and merge work. I have checked and there also seems to be no appropriate extension point to prevent that on the server. There are only places to create behavior for deliver operations.

0 votes


Permanent link
Will this help? https://jazz.net/library/article/649

Developers still do normal deliver, but they need to change to "green stream" to accept.

Jirong

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.

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

Question asked: Nov 30 '11, 2:33 a.m.

Question was seen: 3,815 times

Last updated: Nov 30 '11, 2:33 a.m.

Confirmation Cancel Confirm