Change sets and work items on different RTC repositories
From RTC V3 onwards change sets hosted on one RTC repository can be associated with work items hosted on a different RTC repository. This allows teams to have a central defect/dashboard/work item repository and distributed SCM repositories. See https://jazz.net/blog/index.php/2010/11/05/countdown-to-the-next-rational-team-concert-part-ii-source-control-enhancements/.
Does anyone know whether you can switch to this model mid-project? For example if two independent repositories are then connected to allow one repository to become the single source for work items associated with change sets - would this be possible in the middle of project?
Does anyone know whether you can switch to this model mid-project? For example if two independent repositories are then connected to allow one repository to become the single source for work items associated with change sets - would this be possible in the middle of project?
2 answers
It is my understanding that you can make this switch mid-project, but
that there is not an inter-repository "move work items" operation, so
you would end up in a state where some of the work items for that
project are in the original repository, and the rest are in the central
repository.
Cheers,
Geoff
On 7/19/2011 12:08 PM, johna_owen wrote:
that there is not an inter-repository "move work items" operation, so
you would end up in a state where some of the work items for that
project are in the original repository, and the rest are in the central
repository.
Cheers,
Geoff
On 7/19/2011 12:08 PM, johna_owen wrote:
From RTC V3 onwards change sets hosted on one RTC repository can be
associated with work items hosted on a different RTC repository.
This allows teams to have a central defect/dashboard/work item
repository and distributed SCM repositories. See
https://jazz.net/blog/index.php/2010/11/05/countdown-to-the-next-rational-team-concert-part-ii-source-control-enhancements/.
Does anyone know whether you can switch to this model mid-project?
For example if two independent repositories are then connected to
allow one repository to become the single source for work items
associated with change sets - would this be possible in the middle of
project?
You can get more details on the distributed SCM capability in the article "Flow changes cross repositories with Rational Team Concert" at https://jazz.net/library/article/535
As Geoff said, you can decide to replicate a stream to a different repository any time. The replicated change sets in the new repository will be associated through OSLC to the original work items who remain in the original repository.
Note that some team advisors only work for change sets and work items that belong to the same repository e.g "require work item approval" on the deliver operation). From the "master" work item, you can create a child work item in the same repo as the stream. You can easily keep plan items and stories in one repo, and let the team lead &developers manage the streams, child work items implementing these stories in their own repository and team area (and team area process & advisors). It's flexible because change sets and work items can both be linked to work items from the same repository or from other repositories. Some organizations decide to keep the high level design (plan items..) in one repo and the production effort in other repos.
As Geoff said, you can decide to replicate a stream to a different repository any time. The replicated change sets in the new repository will be associated through OSLC to the original work items who remain in the original repository.
Note that some team advisors only work for change sets and work items that belong to the same repository e.g "require work item approval" on the deliver operation). From the "master" work item, you can create a child work item in the same repo as the stream. You can easily keep plan items and stories in one repo, and let the team lead &developers manage the streams, child work items implementing these stories in their own repository and team area (and team area process & advisors). It's flexible because change sets and work items can both be linked to work items from the same repository or from other repositories. Some organizations decide to keep the high level design (plan items..) in one repo and the production effort in other repos.