Is there a way to detect corrupt RTC workspaces?

Vince Thyng (137●2●33●53) | asked Aug 17 '16, 5:44 p.m.
edited Aug 20 '16, 11:33 a.m. by David Lafreniere (4.8k●7)

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

permanent link

David Lafreniere (4.8k●7) | answered Aug 20 '16, 11:56 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

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)

-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.

Michael Valenta selected this answer as the correct answer

Comments

Vince Thyng commented Aug 25 '16, 12:11 p.m.

1) There was a change set listed in outgoing that we tried right clicking on it, "outgoing", and the component. Deliver was disabled at all 3 levels.
2) We tested delivering to a different component in the same workspace and that worked, so we know the jazz repository connection was still up. This problem did not impact all of the components in the workspace.
3) I can't be 100% certain that there was only 1 flow, but I am pretty sure there was only 1. The workspaces have since been deleted and recreated. I will need to look for All Flows select if this happens again.
4) We expect to see a conflict message and special icon indicating a conflict, which was not present, and there were no unresolved changes present in the pending changes view under this component.

Thank you very much for the ideas!

One other answer

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Kevin Ramer (4.5k●8●178●197) | answered Aug 18 '16, 8:43 a.m.
edited Aug 18 '16, 8:43 a.m.

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

Vince Thyng commented Aug 18 '16, 12:07 p.m.

Thanks Kevin. We tried that first actually and it said that the sandbox did not appear to be corrupt before it even started. Also, I think that only looks at the local sandbox instead of the RTC workspace tracked on the server.

Kevin Ramer commented Aug 18 '16, 3:16 p.m.

Maybe next time:

Check Recent Events on the project for Component changes
Open the target stream to see if there is a component showing as uuid
Component visibility

It's all about the answers!

Related questions

Is there a way to detect corrupt RTC workspaces?

Accepted answer

One other answer

Your answer