Why do RTC components occasionally get disconnected?
Why do RTC components occasionally get disconnected? My colleague came in this morning to find all his RTC components disconnected in one of his streams - he could not accept any incoming baselines without a warning that the component was disconnected. This will cause many hours of reloading and reapplying local changes.
RTC 4.0.7 (client and server), Windows 7, Eclipse environment..
showing 5 of 6
show 1 more comments
|
3 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Jan 15 '15, 2:14 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Jan 15 '15, 2:15 p.m.
I'm not sure how those Eclipse projects would have gotten disconnected. There is an explicit "Team -> Disconnect" operation which would disconnect them, but the user probably would have remembered if they had done that operation. I'll see if I can find out other things that might cause an Eclipse project to become disconnected from an RTC workspace, other than this explicit operation. (If anyone else on the forum has some experience with that, please post a comment here).
But there is a fast/easy way to fix this ... just "share" those projects into Team Concert again. In particular, run the "share" wizard, and the wizard will just reconnect the files in the sandbox back to the RTC workspace. The "share" operation to reconnect the Eclipse project is smart about unresolved changes ... it will detect them, and they will show up in your Unresolved folder. One thing to be careful about ... the wizard will ask you what component to share the project into ... make sure to select the original component. If you select some other component, it will think you want to share this directory into that other component, and create a change set that creates all those files in the other component. But if you make that mistake, it's actually not a big deal ... discard that new share change set, "disconnect" that project, and then run the "share" wizard again, this time picking the right component. Comments I'll give it a go next time it happens. (If it works I'll mark it as an accepted answer) Thanks, Eddie.
I too ran into same issue. Without my intervention, the loaded projects were disconnected. I tried the solution given by Geoffrey to Share again the project in right component, but it does not work in my case. Earlier, I have loaded the component root (say COMP1) as eclipse project and got disconnected suddenly. Now, if I try Team->Share project and select COMP1 as component and finish, it shows the project COMP1 will be added again as a new one inside COMP1. However I'm not able to update the existing root component (COMP1) contents.
But there is a fast/easy way to fix this ... just "share" those projects into Team Concert again. In particular, run the "share" wizard, and the wizard will just reconnect the files in the sandbox back to the RTC workspace. The "share" operation to reconnect the Eclipse project is smart about unresolved changes ... it will detect them, and they will show up in your Unresolved folder. Well, there is also a faster/easier way to fix this ... From Package Explorer view you have to drag the Eclipse project and drop it on the related component on Pending Changes view. Notice that drag-and-drop action only works from Package Explorer view (e.g., not Navigator view). |
Another way is to Load again. Before you do that, make sure you backup your sandbox in case it fails, although it always work for me. Do the normal Load process, select the same directory you had, when you click on Finish, it will give you a warning: "The selected folders collide with projects already in your local file area. Please confirm which ones to re-load". You OK it, then Cancel the Load process, everything will come back |
Yes - I mean 'unloaded' although as you pointed out the error message (incorrectly IMHO) says disconnected. There was no intervention by the user to deliberately unload all eleven components in the stream. In answer to Geoffrey's questions: - Yes all the files were on disc. We verified that by doing a difference with what was expected. My workspace was unaffected. - No other user or process could access his local workspace, it is on a lap-top. - It takes many hours to reload because thousands of files with gigabytes of data became 'unloaded', and we have a relatively slow line here (30 Mbits/second) - There were file changes locally which had no yet been checked in, which had to be 'reapplied' (probably the wrong word again). We have the same problem occasionally and we are not able to identify the cause... It seems occurring when the sandboxes are located on a network driver (i..e, NAS). Any advice?
We are on RTC 5.0.2 (client and server), Windows 7, Eclipse environment.
Thanks in advance.
Cheers.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
How do you mean "disconnected" ? Things I've seen are that the component is removed by someone or the Component got deleted. In some cases the view of the stream ( Eclipse UI, Right click stream, open ) components will show a UUID rather than the component name. That, if I recall, means the Component itself was deleted.
One can see activities like this by looking at the Recent Events for the Project Area.
Thanks Kevin for your response,
By 'disconnected' I mean that the components are no longer 'solid blue upside down T shapes' in the pending changes view, but hollow upside down T shapes. The disconnected warning occurs when accepting baselines from these components.
No changes have been made by anybody else in this stream, other than the automated overnight build process creating a baseline, and my view of the stream does not show this problem, only my colleague's view.
Eddie
There are two different (but related) situations ... both of which can cause the icon to become uncolored. The first is that you have unloaded the component ... in that case, those files would be removed from the sandbox. The second is that you have "disconnected" those Eclipse projects, in which case the files are still there (but the "version-controlled" icon will be gone).
Note that the icon for a stream component will always show "unloaded", because you cannot load a stream ... you can only load a workspace (therefore, the icon for a stream component will always be "unloaded"). So the warning message your colleague got must have come from accepting changes into a workspace (is that right?).
A few questions:
- Were the files from those components still on disk (in the sandbox)?
- Was anyone else (or any other process, such as an automated build) loading this repository workspace into a different sandbox?
- How many files of what size are in the sandbox?
- Does "reapply changes" mean had changes to those files that had not been checked in yet?
Thanks for your responses.I have been using RTC for a year but I'm still getting used to the terminology! Yes - I mean 'unloaded' although as you pointed out the error message (incorrectly IMHO) says disconnected. There was no intervention by the user to deliberately unload all eleven components in the stream. In answer to Geoffrey's questions:
- Yes all the files were on disc. We verified that by doing a difference with what was expected. My workspace was unaffected.
- No other user or process could access his local workspace, it is on a lap-top.
- It takes many hours to reload because thousands of files with gigabytes of data became 'unloaded', and we have a relatively slow line here (30 Mbits/second)
- There were file changes locally which had no yet been checked in, which had to be 'reapplied' (probably the wrong word again).
To solve the issue the user moved the folder that had his changed files to another (non-RTC) location, reloaded all the components and (hours later) copied his files back. He is now working again normally, although the time taken to recover is not really acceptable.
To clarify my second question ... I was wondering whether another user was loading the repository workspace (a server-side object) into their sandbox (a client-side object). If they were, and they made some changes (like checking in new versions), the first user would have gotten a "sandbox out-of-sync" message. But since you were getting projects disconnected, not "out-of-sync", this probably doesn't have anything to do with what you are seeing, so you can ignore this question (:-).