Question about change sets attached to multiple work items
I tried searching for answers but so far haven't found....
Situation: RTC 2.0.0.1 Lead developer requested that approvals be present before code can be delivered. So I added an additional
pre-condition to the "Deliver (Client)" -- Require work item approval
and added that at least 1 approver make the approval.
This had the desired effect, so now developers are submitting for review
and reviewers can view the file from the change set link on the work item.
However, some deliveries are now being attached to multiple work items
and the developers did not expect and do not understand why. I don't think it's a problem; rather more of an understanding of the new function.
I'm trying to deduce why the change sets may get delivered to other work items. In some cases when developer Jan delivers the change set ends up on Jerry's work items because Jerry approved Jan's change set. Sometimes it's not so obvious.
Any tips ?
Thanks -- Kevin
Situation: RTC 2.0.0.1 Lead developer requested that approvals be present before code can be delivered. So I added an additional
pre-condition to the "Deliver (Client)" -- Require work item approval
and added that at least 1 approver make the approval.
This had the desired effect, so now developers are submitting for review
and reviewers can view the file from the change set link on the work item.
However, some deliveries are now being attached to multiple work items
and the developers did not expect and do not understand why. I don't think it's a problem; rather more of an understanding of the new function.
I'm trying to deduce why the change sets may get delivered to other work items. In some cases when developer Jan delivers the change set ends up on Jerry's work items because Jerry approved Jan's change set. Sometimes it's not so obvious.
Any tips ?
Thanks -- Kevin
3 answers
The "deliver" operation does not cause any association between a
change-set and a work item. But note that when a developer "starts
working" on a workitem (transitioning its state to open), it becomes the
"current work" of that developer, and every change-set that developer
creates after that point is automatically associated with that work item
(until they "complete" that work item).
Note that adding a change-set does not currently affect the state of any
approvals. Work item 106036 requests that some types of approvals be
re-opened when change-sets are added to the work item.
Cheers,
Geoff
yzwkzfn wrote:
change-set and a work item. But note that when a developer "starts
working" on a workitem (transitioning its state to open), it becomes the
"current work" of that developer, and every change-set that developer
creates after that point is automatically associated with that work item
(until they "complete" that work item).
Note that adding a change-set does not currently affect the state of any
approvals. Work item 106036 requests that some types of approvals be
re-opened when change-sets are added to the work item.
Cheers,
Geoff
yzwkzfn wrote:
I tried searching for answers but so far haven't found....
Situation: RTC 2.0.0.1 Lead developer requested that approvals be
present before code can be delivered. So I added an additional
pre-condition to the "Deliver (Client)" -- Require work item
approval
and added that at least 1 approver make the approval.
This had the desired effect, so now developers are submitting for
review
and reviewers can view the file from the change set link on the work
item.
However, some deliveries are now being attached to multiple work
items
and the developers did not expect and do not understand why. I don't
think it's a problem; rather more of an understanding of the new
function.
I'm trying to deduce why the change sets may get delivered to other
work items. In some cases when developer Jan delivers the change set
ends up on Jerry's work items because Jerry approved Jan's change set.
Sometimes it's not so obvious.
Any tips ?
Thanks -- Kevin
We've set a pre-condition "Descriptive Change Sets" on deliver as well, so in our case whether it's the deliver or checkin, there are change sets linked to work items.
I think RTC is also "opportunistic" and will associate the change with other work items if they are there.
Another thing I've noticed is that the files that cause change sets to multiple work items were previously modified against at least one of the work items.
I think RTC is also "opportunistic" and will associate the change with other work items if they are there.
Another thing I've noticed is that the files that cause change sets to multiple work items were previously modified against at least one of the work items.
The "deliver" operation does not cause any association between a
change-set and a work item. But note that when a developer "starts
working" on a workitem (transitioning its state to open), it becomes the
"current work" of that developer, and every change-set that developer
creates after that point is automatically associated with that work item
(until they "complete" that work item).
Note that adding a change-set does not currently affect the state of any
approvals. Work item 106036 requests that some types of approvals be
re-opened when change-sets are added to the work item.
Cheers,
Geoff
yzwkzfn wrote:
I tried searching for answers but so far haven't found....
Situation: RTC 2.0.0.1 Lead developer requested that approvals be
present before code can be delivered. So I added an additional
pre-condition to the "Deliver (Client)" -- Require work item
approval
and added that at least 1 approver make the approval.
This had the desired effect, so now developers are submitting for
review
and reviewers can view the file from the change set link on the work
item.
However, some deliveries are now being attached to multiple work
items
and the developers did not expect and do not understand why. I don't
think it's a problem; rather more of an understanding of the new
function.
I'm trying to deduce why the change sets may get delivered to other
work items. In some cases when developer Jan delivers the change set
ends up on Jerry's work items because Jerry approved Jan's change set.
Sometimes it's not so obvious.
Any tips ?
Thanks -- Kevin
Note that the "Descriptive Change Sets" precondition does not cause
change sets to become associated with work items ... it just causes a
deliver to fail if you are trying to deliver a change set that doesn't
already have a work item association (and/or a comment, depending on how
you've configured the precondition).
I'm not sure what you mean by "associating a change with other work
items if they are there". The only auto-association of a change-set to
a work item that I'm aware of is the one I describe below, and that only
links a newly created change-set to the "current" work item, of which
there can be at most one for a given workspace.
I'm also not sure what you mean by:
Note that a file is modified in a change-set, not a work item.
Cheers,
Geoff
yzwkzfn wrote:
change sets to become associated with work items ... it just causes a
deliver to fail if you are trying to deliver a change set that doesn't
already have a work item association (and/or a comment, depending on how
you've configured the precondition).
I'm not sure what you mean by "associating a change with other work
items if they are there". The only auto-association of a change-set to
a work item that I'm aware of is the one I describe below, and that only
links a newly created change-set to the "current" work item, of which
there can be at most one for a given workspace.
I'm also not sure what you mean by:
the files that cause change sets to multiple work items were
previously modified against at least one of the work items
Note that a file is modified in a change-set, not a work item.
Cheers,
Geoff
yzwkzfn wrote:
We've set a pre-condition "Descriptive Change Sets" on
deliver as well, so in our case whether it's the deliver or checkin,
there are change sets linked to work items.
I think RTC is also "opportunistic" and will associate the
change with other work items if they are there.
Another thing I've noticed is that the files that cause change sets to
multiple work items were previously modified against at least one of
the work items.
gmclemmwrote:
The "deliver" operation does not cause any association
between a
change-set and a work item. But note that when a developer
"starts
working" on a workitem (transitioning its state to open), it
becomes the
"current work" of that developer, and every change-set
that developer
creates after that point is automatically associated with that work
item
(until they "complete" that work item).
Note that adding a change-set does not currently affect the state of
any
approvals. Work item 106036 requests that some types of approvals
be
re-opened when change-sets are added to the work item.
Cheers,
Geoff
yzwkzfn wrote:
I tried searching for answers but so far haven't found....
Situation: RTC 2.0.0.1 Lead developer requested that approvals be
present before code can be delivered. So I added an additional
pre-condition to the "Deliver (Client)" -- Require work
item
approval
and added that at least 1 approver make the approval.
This had the desired effect, so now developers are submitting for
review
and reviewers can view the file from the change set link on the
work
item.
However, some deliveries are now being attached to multiple work
items
and the developers did not expect and do not understand why. I
don't
think it's a problem; rather more of an understanding of the new
function.
I'm trying to deduce why the change sets may get delivered to other
work items. In some cases when developer Jan delivers the change
set
ends up on Jerry's work items because Jerry approved Jan's change
set.
Sometimes it's not so obvious.
Any tips ?
Thanks -- Kevin