Disable delievr option for a changeset
Hello,
We have some changesets that we do not intend to deliver regularly. The method is to call the changeset "do not deliver" and remember not to choose it when delivering. Of course we can suspend, but this is not what we want. Is there a better way to perform it? Something like - "lock the changeset". Thanks, Yaron |
9 answers
Hello, Hi yaron, I think you can only lock single files. So depending on your needs there is a number of ways to solve it. One solution could be to move these specific files to another component if there is something special about them. Another solution could be to give ownership of the prod stream you deliver to to a single person so only say a lead developer can pass them on to this stream. If its on a single developer level you can use the "suspend" feature to "park" the changes for later use so they are not delivered. Finally you can look into the eclipse ignore files and remove certain file types or names from the general deliveries. Hope that helps you. |
|
Hello
Thanks for the response. I am familiar with the option that you have suggested. None of them meets my needs. I do not want to lock a file since someone else should be able to change them. I do not want to ignore since they should be sourced controlled. Suspend the changeset would remove changes from my sandbox and I do not want it as well. A solution should be some kind of property that will be related to a changeset that will cause it not to be delivered. Is there an option to do it? Maybe a deliver precondition can be implemented? |
Could you consider move the "do not deliver" change to one seperate changeset, eg names"NOT DELIVER", so when you deliver, do not select this changese, hope the name help to reminder you.
Further more, maybe plus preconsion, auto check if the changeset names "NOT DELIVER", but firstly you should check in the files to "NOT DELIVER" manually. What do you think? |
|
Hi.
The solution that you have described is my current solution. I have thought to have a better solution. Is there any? Maybe we need to have to ask for s new WI that will implement it? |
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 30 '11, 4:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I believe you are looking for the converse of the enhancement requested
in work item 2195 (Provide a "defer incoming changes" operation). I've submitted a new work item 189850 (Provide a "defer outgoing changes" operation). If that accurately defines the functionality you are looking for, please feel free to add a comment to the work item indicating your interest. Cheers, Geoff On 12/25/2011 10:08 AM, yaron wrote: Hello, |
|
Hello Geoff,
It looks like this is what we need. I have added my remark to the WI. Thanks, Yaron |
Hello,It sounds like you don't want to deliver the change set because it's a significant change and needs a lot of work before everything can be delivered. I would suggest creating a duplicate of the stream and deliver the changes there. When everything is stable, you can deliver the changes to the main stream. |
Hello,It sounds like you don't want to deliver the change set because it's a significant change and needs a lot of work before everything can be delivered. I would suggest creating a duplicate of the stream and deliver the changes there. When everything is stable, you can deliver the changes to the main stream. I agree with Tim here that making aseperate stream sounds like the right way to work here. |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Jan 04 '12, 9:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I'd probably create another workspace, rather than another stream.
Have your original workspace be your "to be delivered now" workspace and the new workspace be your "to be delivered later" workspace. Your "to be delivered later" workspace would accept changes from both the stream and the "to be delivered now" workspace. And if you change your mind about what whether a change-set should be delivered now or should be delivered later, just suspend that change-set from the one workspace and resume it in the other. The reason I'd use another workspace rather than another stream is so that you can resolve conflicts in either workspace (you can only resolve conflicts in a workspace, not a stream). The reason I'd use an additional workspace is that you want to do a validity build on the configuration before you deliver it (minimally a compile, and preferably some automated tests), and for that, you're going to need a workspace that contains only the "to be delivered now" changes. Cheers, Geoff On 1/3/2012 12:23 PM, tmok wrote: yaronwrote: |
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.