On Wed, 06 Feb 2008 17:57:57 +0000, ericlee wrote:

If I look at incoming changesets for a stream and decide that I don't
want to accept it, is there a way to explicitly reject it?

You can simply not accept it.

Is there something more that you think "rejecting" a changeset should do?

- Dmitry

On Wed, 06 Feb 2008 22:17:55 +0000, ericlee wrote:

Let's take an extreme example. Let's say I have a stream with an
incoming change-set from a developer named Tom.

Let's say Tom is malicious employee and gets fired. How do I deal with
his incoming change-set in my stream? Ideally, I would like to
reject/delete it. But if there is a defer I can at least hide it.

You can accept the change and then reverse it. This will undo what Tom
has done.

- Dmitry

See Enhancement Request 2195.
This asks for a "defer" operation, that indicates you don't want to see
it in your "pending incoming changes" list. I prefer the word "defer"
rather than "reject", since "reject" is easily confused with the current
"reverse" operation.

Cheers,
Geoff

Dmitry Karasik wrote:

On Wed, 06 Feb 2008 17:57:57 +0000, ericlee wrote:

If I look at incoming changesets for a stream and decide that I don't
want to accept it, is there a way to explicitly reject it?

You can simply not accept it.

Is there something more that you think "rejecting" a changeset should do?

- Dmitry

Ah ok, a 'defer' option would be fine.

I was just hoping to not see that changeset in my pending changes if I didn't want to accept it.

Thanks!

Eric.

You will not be able to accept any changes that build upon it. At some
point either you will need to accept the change, or the stream needs to
be rolled back in order to remove that change.

Can you explain to me what characteristics a change-set would have so
that you would not be ok with seeing it as incoming?

JohnC
SCM Server

ericlee wrote:

Ah ok, a 'defer' option would be fine.

I was just hoping to not see that changeset in my pending changes if I
didn't want to accept it.

Thanks!

Eric.

I'm new to streams, so I might not be understanding something about them.

Let's take an extreme example. Let's say I have a stream with an incoming change-set from a developer named Tom.

Let's say Tom is malicious employee and gets fired. How do I deal with his incoming change-set in my stream? Ideally, I would like to reject/delete it. But if there is a defer I can at least hide it.

Is there a better way to handle this scenario?

Thanks!

Eric.

ericlee wrote:

Hey guys,

If I look at incoming changesets for a stream and decide that I don't
want to accept it, is there a way to explicitly reject it?

Thanks,

Eric.

Before I explain your options in this scenario, there is a consideration
that must be made when you deal with change-sets: think about how to
flow your change-set decisions to others on your team. For example, if
you decide to reject a change-set, how will your team members see this
and what happens when others have built upon this change-set.

The normal flow of change-sets is for them to build upon each other and
then you deliver to flow them to one or more streams. This means that if
someone delivers something you don't like, you can reverse the entire
change-set, which essentially creates a new change-set with the opposite
effect, then you flow this new change-set to the team and they simply
accept. You don't delete or reject the change-set itself, as it is still
in the history, but you undo it's effect. This is easier and works in
all cases, even when the change-set is old and others have built upon it.

But there is also an alternate work-flow, which is meant as more of a
safety net than a usual tool. You can replace the contents of a
component in a stream with the contents in your repository workspace.
This is essentially how you can "reject" change-sets. You can use the
discard action on your workspace to remove any change-set you don't
like, assuming that nothing too complicated has built on it, and then
run the "Replace In > <stream name>" action on the component node or
workspace node from the pending changes view. The stream will now look
exactly like your workspace, effectively removing the change-sets you
discarded from yours. We will also keep a backup of the state right
before running the "Replace In" action that can be accessed from the
baseline history of the component. We are still working on how others on
your team know that you rejected the change-sets, see the discussion in
https://jazz.net/jazz/resource/itemName/WorkItem/23621, but we are
looking at making this work-flow more user friendly for 1.0.

The summary is:

1. Recommended approach is to accept, reverse with the action of
manually, and deliver the undone changes.

2. Alternate to really rejects, use the "Replace In" action in the
pending changes view.

HTH,
Jean-Michel
Jazz Source Control Team

"Jean-Michel Lemieux" <Jean-Michel_Lemieux@ca.ibm.com> wrote in message
news:foduan$a64$1@localhost.localdomain...

The normal flow of change-sets is for them to build upon each other and
then you deliver to flow them to one or more streams. This means that if
someone delivers something you don't like, you can reverse the entire
change-set, which essentially creates a new change-set with the opposite
effect, then you flow this new change-set to the team and they simply
accept. You don't delete or reject the change-set itself, as it is still
in the history, but you undo it's effect. This is easier and works in all
cases, even when the change-set is old and others have built upon it.

but just to be clear, there's a difference between "building upon" a change
set and
"depending upon" somehting in it. In the latter case, accepting the
reversion of the change
set you depend upon must break that dependency...?

OK, I see what my initial confusion was about. I thought that a delivery wasn't visible in the stream until it was accepted. That was just confusion on my part.

OK, now I understand why you need to see change sets as incoming most (if not all) of the time.

Thanks!

Eric.