Is there a way to detect corrupt RTC workspaces?
Multiple users in a project area recently reported that they could not deliver to some components because the deliver option was grayed out. Other components still worked as expected. All components are owned by the same process area (the project area). Creating a new RTC workspace solved the problem. Is there a way to detect, see, and/or repair all corrupted workspaces on a server?
Accepted answer
Here are some 'valid' cases where the action might be disabled. Please check if any of the following match the cases you are seeing:
-There are no outgoing change sets (or baselines)
-The Jazz repository (In the Team Artifacts view) is logged out (either from a manual log out, or the server went down)
-When using the "All Flows" mode in the Pending Changes view (and when trying to deliver a CS where the flow target is the workspace itself)
-The Jazz repository (In the Team Artifacts view) is logged out (either from a manual log out, or the server went down)
-When using the "All Flows" mode in the Pending Changes view (and when trying to deliver a CS where the flow target is the workspace itself)
-One of the files in the outgoing change set you are trying to deliver is in conflict. The conflict would need to be resolved first, and would appear in the 'Unresolved' folder.
Can you also please mention whether or not the he "All Flows" mode is used in the Pending Changes view, and whether or not you have component hierarchies (in either the workspace, or the stream being used)?
If you ever figure this out, can you please remember to update this post? I have not seen a case when the "Deliver" context menu action is incorrectly disabled, but am curious to know why.
Comments
One other answer
There is a "Repair Metadata" available on the Eclipse RTC preferences panel. Path: Windows / Preferences / Team / Jazz Source Control May or may not fix, but worth try.
Comments
