It's all about the answers!

Ask a question

How to delete check-in files but not yet delivered in RTC?

Don Yang (7.7k21108137) | asked Aug 26 '22, 2:40 a.m.
User is at v6.0.6. They notice the scm related tables size grows too quick to multiple TBs.
Follow the suggestions in
we are able to collect Mxbeans for scm contents top ranked scm files and found many of them at size xxGB are only checked in files not yet delivered. Due to some wrong use cases by the end users, those files become orphaned and
the owners left the company. They want to delete those large files in order to free up the DB space.

Following the procedures in this article,, it suggests to delete the contents from the history versions which do not seem to apply to this user's situation, there is no history of the delivery at all, those files are like the below:

History is empty:

How do we delete these type of files in RTC?


Ralph Schoon commented Aug 26 '22, 3:06 a.m.

In the pending changes view, can you try to do an Undo on the outgoing change on the file? For me, that removed the checked in file from the repository. 

I would suggest to set the limits for file sizes or introduce an external binary repository for huge files.


Don Yang commented Aug 28 '22, 10:45 p.m.
Thanks Ralph for the suggestions.
Would Undo delete the files from DB? As check-in files would store in DB and that's the main concern currently, and we want to delete those files.

Accepted answer

permanent link
David Lafreniere (4.8k7) | answered Aug 29 '22, 2:56 p.m.

Unfortunately I don't think the Undo action from the PC view will delete the actual content from the DB. It will remove that filestate from the change set however, but the filestate+content blob is already in the DB prior to that. It sounds like even if the 'Undo' action did work, it might not solve all your original issues because from what I gather  there are also 'complete/closed' change sets which contain these large binary files that you want to clean-up - in which case the 'Undo' action won't work..

The approach you want is what you first started describing... however the issue is that you are trying to show the History of that file in an empty configuration. Ex: Notice it says "android-8.1.0_r33.tar.gz in Empty configuration" at the top of the History view... which in turn is because the Change Summary view also doesn't have a context, what you need is for this change set to exist in 'any' stream/repository workspace, and use that context in the Change Summary view first, and then the Show History action will actually show you the change set, in which case you can do the check-in history --> Delete Content action.
(Note: there's an action on the toolbar of the Change Summary view called "Select location to resolve paths" that can be used to change to a workspace/stream that contains the change set. If the repo workspace that 'did' have the change set is deleted, then create a temporary repo workspace and accept the change set into that workspace, and you can delete the repo workspace once all your content deletes are done).

Don Yang selected this answer as the correct answer

Don Yang commented Aug 29 '22, 11:13 p.m. | edited Aug 29 '22, 11:14 p.m.
Hi David

Thanks a lot for the details.
I am able to locate some files in the repository by searching for component, then its owner project area and from there go to the component and patch I have got to locate the file and show History. But this does not work for most of the large files we have got from ccm Repodebug > mxBeans > scm contents > Top contents. For example
top contents shows one large file with the path like
/BOOT_Doc_Rel/RH850_BOOT_1222_xxxxx/SI/New folder2.z01   
component is: Bootloader

I then locate the component and its project area. when opening the target file New folder2.z01, I got
However, from the stream or repository workspace, I see
As you can see, there is no folders "RH850_BOOT_1222_xxxxx/SI" at all.
You mentioned that "If the repo workspace that 'did' have the change set is deleted, then create a temporary repo workspace and accept the change set into that workspace, and you can delete the repo workspace once all your content deletes are done", I try to Accept the changesets

The author left the company and it is orphaned file now. I did not try Patch option as I am not sure what would happen after that. Is there anything we can try further from here or for this type of situation?

David Lafreniere commented Aug 29 '22, 11:27 p.m.

Ah, so this actually is a case of the change set still being active/open. This means that the change set only exits in the users repository workspace. I say this because if they were to actually deliver it anywhere, the deliver operation automatically completes/closes the change set. Also if the user were to perform the Discard operation, then that's another operation that auto-completes / closes the change set. If you know the owner (person that left) you could perform a search for Repository Workspaces owned by that owner (you have to select a button to show archived users in the user picker dialog). You can perform a Locate Change Sets action on the change set, then drag and drop all repo workspaces into the Locate Change Sets editor Search Target section, and with some luck you'll find the repo workspace that contains the change set.
From there you could then change the Change Summary context to that repo workspace and then do the show History. Also, FYI, it's possible to change the owner of a repo workspace to a new user (an admin can do this), this in turn allows you to re-take ownership of active change sets, in case you wanted complete it or do something else with it.

Don Yang commented Aug 31 '22, 8:39 p.m.
Thanks a lot David for the details on this scenario. I did not realize I can search for the archived user's repository workspace from the found changeset view(search view > right click on the user > creator(or user name) > Search for Repository), from the repository workspace, we see the files and show history would then lead to the menu for us to delete the contents.
There are some files which would need to follow you previous suggestion "create a temporary repo workspace and accept the change set into that workspace" to perform the deletion.

David Lafreniere commented Aug 31 '22, 8:42 p.m.

Glad that helped.
One other thing to mention is that a repository workspace can have a visibility of either public or private. So unless you are logged in as a user with repo wide ADMIN permissions, you might not be able to find all the private repository workspaces.

Your answer

Register or to post your answer.