In a regulated environment the compliance with development processes need to be proved. An organization needs to be able to access all artifacts for about 10-15 years depending on the regulation requ...
In the purest sense, there are only two ways to do a review: "pre-merge", which allows for parallel reviews but makes no guarantee that the code ultimately committed is the same as what was reviewed, or "post-merge", where all the reviews and commits are necessarily serialized (only one review and commit at a time). In a post-merge world-- where every commit is absolutely traceable to a review-- it's the version control system, not Collaborator, that's the sensible authority for the source code itself. In that case, there's no real need for Collaborator to hold onto its own copy forever. Even Collaborator calls it a "content cache", not a "repository"; and it's not very efficient at that. It should be able to reach out to the VCS and retrieve whatever version of any file that it needs (if the file's no longer in your version control system, you've got bigger problems.) As you point out, projects get cancelled, reach end-of-life, and so on. What would be very nice is an "archive" function that actually works: You set up search terms matching the reviews you'd like to archive (including searches on custom fields), Collaborator previews the result set, and then generates an archive file (.zip, .tbz., whatever) containing all of the necessary database information, label (table of contents) information, plus all relevant files from the content cache. When you certify that the archive file has been safely copied off to long-term storage, you notify Collaborator of that fact and it then cleans up the database and cache appropriately. To actually be an "archive", it would also need to be able to restore an archive back into the active database like it was never gone. From a programming standpoint that's not a trivial effort, but it's certainly possible.