I would really appreciate some thoughts about this important topic for our possible migration from ClearCase to RTC.

1) My understanding is that moving to new RTC versions at least sometimes involves downtime, the larger the repository the longer the downtime. Would someone please comment on when this is necessary and when not (every major release?). Would someone also comment on the downtime (if any) for regular backups, assuming an Oracle database?

2) We cannot tolerate downtimes when all development simply stops for long periods of time. So we have to think very carefully about the obvious first idea of putting everything into one repository. It is helpful here to compare CC vobs with the RTC repository. Vobs are not monolithic, since they can be freely combined in a view. I have the impression RTC tends to assume that everything is in one repository.

3) We have a lot of data, consisting of chip designs, firmware, software and all sorts of documentation. We have two sorts of projects: (1) Chip projects, which tend to be relatively self-contained and generate a lot of data (e.g. GB size binary files). These tend to have definite life-spans of 1-2 years. (2) Firmware and software projects, which do not have such large files, but have many files and last for a long time; hence they accumulate a lot of data over time.

4) Given what I know or guess so far, I tend to think we should create separate RTC repositories for each chip project and one repository for the FW/SW/Doc. Is there any real experience here? Has RTC been deployed in such an area already? One problem here is that there is some reuse between the different areas. The least we would need is the ability to reuse components read-only from other repositories (i.e. the CC UCM "add component from other pvob"). I am also worried about work-item tracking and the various project planning and execution functions of RTC. The chip, FW, SW and Doc development come together in system projects. A defect or task may have implications for all four; the project planning involves all four. Will this really work with artifacts split into different repositories, or will we find real limitations?

5) If the best decision functionally is one repository, we would need something like an archive feature, which would allow us to "carve out" a project and its data into a separate repository. We could then execute a chip project to completion in the main repository and archive it into another repository, where it would be available (with functional limitations) if we ever needed to revisit it. This would, with luck, ensure that the main repository does not grow at an unacceptable rate. Any ideas about the feasibility of this sort of feature?

Feel free to expand the discussion if I have missed relevant considerations.

-David