repository housekeeping for RTC
All things being equal, a smaller repository is better than a bigger repository, so some "housekeeping" functionality to clean out trash and put things into storage is necessary.
Comments about the following proposals are welcome:
1)RTC needs a ClearCase rmelem . The main use is to completely remove files that were mistakenly added to the repository. Normally, this will not be used after significant development, when, for example, baselines could be damaged due to missing files. There should be lots of restrictions on its use.
2)RTC needs a ClearCase rmversion . The main use is to remove "uninteresting" versions (e.g. intermediate versions that appear in no baseline). There should be lots of restrictions on its use.
3)RTC needs a way of archiving a component . Here is a proposal:
3.1) An archived component is like any other component, except that the contents of the files are not stored in the working repository, but in a secondary repository (e.g. a 2nd Oracle database). Versions, baselines, etc. are all still available in the main repository.
3.2) Anything that requires only the metadata of a component (e.g. showing the component in a stream, displaying baselines) remains exactly as is, except that archived components are marked as archived.
3.3) Anything that requires the actual contents of the files (e.g. load) is obviously not available.
3.4) An archived component can be restored from the secondary repository. The result is that the component is just as it was in the main repository before it was archived.
4)RTC needs a way of archiving an individual file . This is similar to archiving a component, but at the level of files. The archived file behaves as a normal file as far as metadata goes, except that it is marked as archived and its contents can't be loaded. (It is empty in the sandbox.) An archived file can be restored.
5)There probably need to be archiving options for larger, more complex chunks of data - e.g. project s. The crucial thing here is that links into this data behave as sensibly as possible when the data is no longer there in the main repository.
Comments about the following proposals are welcome:
1)
2)
3)
3.1) An archived component is like any other component, except that the contents of the files are not stored in the working repository, but in a secondary repository (e.g. a 2nd Oracle database). Versions, baselines, etc. are all still available in the main repository.
3.2) Anything that requires only the metadata of a component (e.g. showing the component in a stream, displaying baselines) remains exactly as is, except that archived components are marked as archived.
3.3) Anything that requires the actual contents of the files (e.g. load) is obviously not available.
3.4) An archived component can be restored from the secondary repository. The result is that the component is just as it was in the main repository before it was archived.
4)
5)