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

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?

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,

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

Hello Geoff,

It looks like this is what we need.
I have added my remark to the WI.

Thanks,

Yaron

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

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,

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

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.

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:
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

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.