Is there the possibility to force the association of a WI during the check in operation?

Thanks in advance
Bye

Hi Andrea, there is only one to enforce on delivery, which is what you really want. Check in only loads changes to the private workspace of the user. The deliver operation is the one that shares the change with the team.

You can configure this operation in the Eclipse Project area/Team area editor on the process configuration tab. Select Team Configuration>Operation Behavior in Source Control>Deliver Server for examle you can select the Require Workitems and Comments precondition.

Hi Andrea, there is only one to enforce on delivery, which is what you really want. Check in only loads changes to the private workspace of the user. The deliver operation is the one that shares the change with the team.

You can configure this operation in the Eclipse Project area/Team area editor on the process configuration tab. Select Team Configuration>Operation Behavior in Source Control>Deliver Server for examle you can select the Require Workitems and Comments precondition.

Ralph, thanks for your answer.
I'm aware of the fact that it's possible to configure RTC in order to force the association of a WI during delivery operation.

In my organization, since we centralized the operation of delivery to one person per team (allowing the developers to perform only check in into their personal workspaces), I was wondering if it would be possible to force the WI association also during check in phase.
In this way, when the delivery operation to the stream will be done, all the links between development workspaces and WIs are already in place.

Thanks again for your support. Regards,
Andrea

Hi Andrea,

in general it is possible to create extensions for operational behavior. I am not sure it would be possible to create something like what you desire. The reason, before check in there is nothing that you could hook into. The change is just created. You could however look into it of course.

What you should really consider, I think, is to have a team stream, where you integrate and then have the integrator deliver selected changes to an integration stream that integrates across teams. That is how RTC is designed.

I believe you are preventing yourselves to take advantages from far too many capabilities RTC provides. For one thing you risk changes not being checked in to be lost due to various reasons. Also you prevent your evelopers from being able to load other workspaces (to prevent loosing the local changes). You also prevent developers from being able to collaboreate (e.g. review) changes. All this due to the policy you describe. This is something the private workspace provides and makes it so valuable.

Hi Ralph,
before starting to use RTC we thought about different usage scenarios, keeping in mind also the collaboration features that RTC offers (the one you described into your message).
The rationale behind our decision is due to the specific software developed, internal access/visibility mechanisms and to maintain a similar behavior of the currently used approach. So, we decided to configure RTC in order to have:
- single person responsible for integration phase into project stream (WI selection for integration based on project needs, merging and conflicts resolution)
- developers working in parallel without collaboration stream (better said, they can collaborate on a need basis by pointing/seeing other developers' workspaces)

In this scenario RTC works perfectly for us, apart from the possibility to force developers to indicate a WI during check in phase.
If this feature is not "bundled" into RTC, I think I could also manage to write a specific plugin, if it's technically feasible.

Thanks and regards,
Andrea

Hi Andrea,

Here is a workshop that tells you ho to create such extensions in general: https://jazz.net/library/article/634 . Things like this are discussed in the Extending Team Concert Forum.

I am not sure there is a hook for what you want. It would have to prevent adding a change to a change set that has no work item associated.

Last time I checked, the "checkin" operation was not process-enabled, so
you would not be able to add process advisers or participants for checkin.

The principle is as follows: A developer should always be able to save a
personal copy of their code on the server, which is what "checkin" does.
No process should ever get in the way of that. In particular, they
should be able to checkin multiple states of "partially completed" code
that aren't ready to deliver to the team stream.

Andrea:
I would suggest the following:
Create a "dev stream" that developers deliver their code to when they
think the code is ready, and then have your integrators deliver from
that dev stream to the team stream.
This allows you to put the process controls you want on the developers,
while still giving your integrators control over what gets into the team
stream. This actually makes life easier for your integrators, since
instead of having to select from a long list of developer workspaces,
they can select change sets from a single stream.

Cheers,
Geoff


On 6/21/2011 11:38 AM, rschoon wrote:

amantovaniwrote:

Hi Ralph,
before starting to use RTC we thought about different usage
scenarios, keeping in mind also the collaboration features that RTC
offers (the one you described into your message).
The rationale behind our decision is due to the specific software
developed, internal access/visibility mechanisms and to maintain a
similar behavior of the currently used approach. So, we decided to
configure RTC in order to have:
- single person responsible for integration phase into project
stream (WI selection for integration based on project needs, merging
and conflicts resolution)
- developers working in parallel without collaboration stream
(better said, they can collaborate on a need basis by pointing/seeing
other developers' workspaces)

In this scenario RTC works perfectly for us, apart from the
possibility to force developers to indicate a WI during check in
phase.
If this feature is not "bundled" into RTC, I think I could
also manage to write a specific plugin, if it's technically feasible.

Thanks and regards,
Andrea

Hi Andrea,

Here is a workshop that tells you ho to create such extensions in
general: https://jazz.net/library/article/634 . Things like this are
discussed in the Extending Team Concert Forum.

I am not sure there is a hook for what you want. It would have to
prevent adding a change to a change set that has no work item
associated.