Possible solution to moving all project data to a new instance
We have an instance of RTC with several major products being developed on it. This causes significant difficulty in finding acceptable maintenance windows, even on the weekend as each product has a different release cycle. To separate out major products, I would like feedback on whether it would work to copy the entire repository to a new server, rename it, and then delete all work items, data in the components, and archive the other projects so you are left with just the project of the team that is moving off the original server.
|
2 answers
Hi Vince,
I think that should be OK. However I don't believe this is one of the supported scenarios for server rename.(Pilot to Production or Production to Test) In addition deleting data in the repository is a lot of manual work, so if the repository is not too big you can probably just keep the extra data and just hide them so that users don't see it? For removing scm data from repository https://jazz.net/library/article/1006 There is a RFE for component deletion, see more information below. https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=163568 For Work item deletion: https://www-01.ibm.com/support/knowledgecenter/SSYMRC_6.0.0/com.ibm.team.workitem.doc/topics/t_deleting_work_items_web.html |
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 26 '15, 6:01 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
This approach to splitting a repository is not officially supported. In particular, when you do a server rename, all other repositories that have a reference to the renamed repository effectively have their references redirected to the new location of the repository. That is fine for the artifacts that are intended to live in the renamed repository, but for references to the artifacts that are intended to live on in the original repository, those references will also be redirected to the renamed repository, where they either will be not found (if they have been deleted), or an old/archived copy in the renamed repository will be found.
If you do not have any external references to artifacts in the repository you are splitting, then this approach might work, but since it is not a supported mechanism, it has not been tested at all by the product team (perhaps someone else knows about known issues, beyond the one I mention above). Comments I am thinking if I am moving 2 projects to their own repositories, I would copy everything twice, and rename the data in each new instance. And it would probably be important delete the work items from the original server, which will still be running for the remaining projects, so people do not end up reading an old version of the work item. External URLs on a wiki for example would need to be updated for the 2 moved projects to look to the new server name. The work item numbers would remain the same.
Geoffrey Clemm
commented Dec 02 '15, 1:04 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The underlying server rename machinery maintains translation tables that automatically map URL's to their "current" location. With the approach you describe, some things will work, some things will obviously break, and some things will seem to work but will break in obscure ways. Since this approach is neither supported nor tested, it isn't something I would recommend for any production repository.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.