CheckIn&Delivery:Different behaviour for different menu
Hi!
Let's say I have a java file in my project linked with a component in a RTC workspace.
I perform some modifications.
Option 1
I righ-click the file and select "Check-In & Deliver": the wizard force me to select a work item or create a new one. In any case RTC is enforcing the relationship between Configuraion Management & Agile planning. GOOD!
Option 2
I righ-click the file and select "Check-in --> New Change Set": RTC force me to enter a comment to the change set but not force me to link the CS to a Work Item: NO GOOD!
Is this the expected behaviour?
There is a way to limit option 2?
Thanks!
Matteo
Let's say I have a java file in my project linked with a component in a RTC workspace.
I perform some modifications.
Option 1
I righ-click the file and select "Check-In & Deliver": the wizard force me to select a work item or create a new one. In any case RTC is enforcing the relationship between Configuraion Management & Agile planning. GOOD!
Option 2
I righ-click the file and select "Check-in --> New Change Set": RTC force me to enter a comment to the change set but not force me to link the CS to a Work Item: NO GOOD!
Is this the expected behaviour?
There is a way to limit option 2?
Thanks!
Matteo
6 answers
Hi!
Let's say I have a java file in my project linked with a component in a RTC workspace.
I perform some modifications.
Option 1
I righ-click the file and select "Check-In & Deliver": the wizard force me to select a work item or create a new one. In any case RTC is enforcing the relationship between Configuraion Management & Agile planning. GOOD!
Option 2
I righ-click the file and select "Check-in --> New Change Set": RTC force me to enter a comment to the change set but not force me to link the CS to a Work Item: NO GOOD!
Is this the expected behaviour?
There is a way to limit option 2?
Thanks!
Matteo
Actually - that is working as it is supposed to. Let me try and explain:
Checkin is putting the file on the server, in *your* repository workspace. No-one else can mess with the file and it is not affecting anyone else. You don't need to associate with a work item yet.
The deliver part is where you place the file in the stream, and everyone else can see it. They will be notified if they also deliver to the stream, etc. At this point, you will be asked to associate a work item - when you are ready to share what you have done.
If this still worries you, then drag the relevant work item to the bottom of the Eclipse UI. The UI will remember you are working on that work item (you can change it later if you want to) - and will automatically associate the work item with all the changes you are about to deliver.
One useful implication of the two steps of check-in and then deliver, is people can make sure their files are safely stored on the server by a check-in. You can lose your local machine and the files are safe on the server.
Apologies if you know about this already
anthony
Hi Anthony and thanks for your response.
The two phase delivery works perfect for me.
The problem is that associating the delivery with a work item is not mandatory: only to insert a comment is required.
So I'm forced to ask to all my team members to follow the Best Practice of using work items during delivery but I cannot FORCE tham to do this.
what do you think?
Thanks and best regards,
Matteo
The two phase delivery works perfect for me.
The problem is that associating the delivery with a work item is not mandatory: only to insert a comment is required.
So I'm forced to ask to all my team members to follow the Best Practice of using work items during delivery but I cannot FORCE tham to do this.
what do you think?
Thanks and best regards,
Matteo
Hi Anthony and thanks for your response.
The two phase delivery works perfect for me.
The problem is that associating the delivery with a work item is not mandatory: only to insert a comment is required.
So I'm forced to ask to all my team members to follow the Best Practice of using work items during delivery but I cannot FORCE tham to do this.
what do you think?
Thanks and best regards,
Matteo
Hi
It is easy to change the behaviour. Your default process is to allow either comments or work items. If you go into the process tab of the project area - you can change the settings there. Let me find the exact location for you and post in a minute.
regards
anthony
In Team Configuration, select Operation Behavior.
Under Operations, select the Everyone column in the Source Control ->
Deliver Phase 1 (server) row.
The "Preconditions and follow-up actions are configured" checkbox should
be checked (if it isn't, check it).
Select the "Require Work Items and Comments" Precondition.
In Constraints, in "On deliver, change sets require" radio buttons,
select the "an associated work item" radio button.
Cheers,
Geoff
kesterto wrote:
Under Operations, select the Everyone column in the Source Control ->
Deliver Phase 1 (server) row.
The "Preconditions and follow-up actions are configured" checkbox should
be checked (if it isn't, check it).
Select the "Require Work Items and Comments" Precondition.
In Constraints, in "On deliver, change sets require" radio buttons,
select the "an associated work item" radio button.
Cheers,
Geoff
kesterto wrote:
zanchiwrote:
Hi Anthony and thanks for your response.
The two phase delivery works perfect for me.
The problem is that associating the delivery with a work item is not
mandatory: only to insert a comment is required.
So I'm forced to ask to all my team members to follow the Best
Practice of using work items during delivery but I cannot FORCE tham
to do this.
what do you think?
Thanks and best regards,
Matteo
Hi
It is easy to change the behaviour. Your default process is to allow
either comments or work items. If you go into the process tab of the
project area - you can change the settings there. Let me find the
exact location for you and post in a minute.
regards
anthony