moving a project to a new repository
We have an RTC project that we need to move to a different repository. Moving projects is a feature that didn't make it into 3.0 (plan items 93151 and 87778, Project Move design note), so we are looking for alternatives. Our project shares a 2.0.0.2 repository in Beijing with 100 unrelated projects. We need to move the project to a new 3.0 or 3.0.1 repository in Raleigh.
About the project:
All we really need to move are the work items, with their links and attachments. We can recreate the users, teams, process config and other project data. Without the project move feature, it seems our options are to copy the work items to a new repository, or copy the whole repository. Both approaches have limitations or problems.
Moving (copying) work items
With 2.0.0.2, copying work items with csv export/import loses too much information. 3.0 and 3.0.1 have higher fidelity work item export/import (work item 100993). Although our Beijing repository is 2.0.0.2, we could make a copy and upgrade the copy to 3.0.1 in order to export work items with 3.0.1. We need more details on the capabilities and limitations of csv export/import in 3.0.1, the information outlined in work item 148415.
Attachments are not copied by csv export/import. Would the RTC API allow us to copy attachments from the original work items to the work items we import into the new repository? I imagine that is possible, but what happens to attachment links in the comments during export/import?
How does export/import of work items affect the RQM integration? Would we use repotools -modifyLinkURIs on the RQM repository to retarget links in RQM to the work items copied to the new RTC repository?
Copying the repository
Another approach would be to copy the repository from the Beijing server to the Raleigh server, and archive all the other projects in the new copy, leaving only our project visible. There are several documents and work items about problems that can happen when changing the public URI.
Yet, forum posts indicate some people have moved repositories and changed the public URI without problems. Does copying with repotools export/import solve any URI problems that would happen when simply moving RTC, DB2 and WAS files to a different machine? We've copied a 2.0.0.2 repository with repotools to test upgrading to 3.0 upgrade, and haven't found any problems, but perhaps we aren't looking in the right places. We also have a production repository that was copied from another repository in RTC 1.0, and both those repositories have no problems.
In our project described above, where should we look for problems if we copy the repository? Particularly for work items, since we could recreate anything else that has problems.
Related documentation and work items: 119503, 127009, Planning your URIs, Changing port numbers,
Thank you,
Greg Pflaum
About the project:
- 8,000 work items
- 5,000 work items have attachments
- No source code or builds
- Little or no use of plans, reports or dashboards
- 300 work items have links to RQM test cases.
All we really need to move are the work items, with their links and attachments. We can recreate the users, teams, process config and other project data. Without the project move feature, it seems our options are to copy the work items to a new repository, or copy the whole repository. Both approaches have limitations or problems.
With 2.0.0.2, copying work items with csv export/import loses too much information. 3.0 and 3.0.1 have higher fidelity work item export/import (work item 100993). Although our Beijing repository is 2.0.0.2, we could make a copy and upgrade the copy to 3.0.1 in order to export work items with 3.0.1. We need more details on the capabilities and limitations of csv export/import in 3.0.1, the information outlined in work item 148415.
Attachments are not copied by csv export/import. Would the RTC API allow us to copy attachments from the original work items to the work items we import into the new repository? I imagine that is possible, but what happens to attachment links in the comments during export/import?
How does export/import of work items affect the RQM integration? Would we use repotools -modifyLinkURIs on the RQM repository to retarget links in RQM to the work items copied to the new RTC repository?
Another approach would be to copy the repository from the Beijing server to the Raleigh server, and archive all the other projects in the new copy, leaving only our project visible. There are several documents and work items about problems that can happen when changing the public URI.
Yet, forum posts indicate some people have moved repositories and changed the public URI without problems. Does copying with repotools export/import solve any URI problems that would happen when simply moving RTC, DB2 and WAS files to a different machine? We've copied a 2.0.0.2 repository with repotools to test upgrading to 3.0 upgrade, and haven't found any problems, but perhaps we aren't looking in the right places. We also have a production repository that was copied from another repository in RTC 1.0, and both those repositories have no problems.
In our project described above, where should we look for problems if we copy the repository? Particularly for work items, since we could recreate anything else that has problems.
Related documentation and work items: 119503, 127009, Planning your URIs, Changing port numbers,
Thank you,
Greg Pflaum