For the past couple of months, I’ve acted as the Rational Team Concert (RTC) SME/expert for a small number of IBM interns developing for a promising project (around IBM BlueMix platform). Especially around the RTC project set up and more regularly on RTC SCM-related trainings and questions.
In the past days, I’ve helped one of these interns at recovering some source code in RTC. This area is actually well documented:
Reference articles / resources:
- [Jazz.net] Topic: “My sandbox is out of sync with my repository workspace. How did that happen? What do I do?” of the Jazz Source Control FAQ
- [Jazz.net] Finding Lost Content with Rational Team Concert (by H. Fraser-Dubé)
- [Blog post] Navigating the history of your file changes in RTC 4.0 (by J. Diaz)
In the case raised by this intern, I was mentioned that:
- for some times already, he experienced some RTC error message explaining his RTC sandbox was “out of sync with the repository workspace“.
- since morning, he could not load a particular SCM component anymore (despite other members of the team still could do it). Loading would systematically fail for some obscure reason (linked to an “Error processing changed links in project description file. : is an invalid character in resource name ‘C:’”) associated to the .project file. I’ll avoid jumping into cause since I still have no clue here (maybe an Eclipse problem, but who knows…)
Having checked for the availability of a backup with the intern, my first thought on this was: “it should not be of a big deal anyway”. I already had pointed him the article [1] as a one-stop-shop for recovering from such situations (esp. by unloading/reloading of components).
But it turned out that, in this particular case, we couldn’t have the problem fixed. As I mentioned before, the component reloading would systematically fail. Based on this, we decided to start fresh and recreate an Eclipse sandbox and a new repository workspace. As a result, we got… the same “invalid character” problem. Humhhh… that was interesting…
Our next action consisted in switching back to the initial sandbox (now with all the components unloaded and so far no more loadable). Investigating the repository workspace history, we discovered that the source code modifications that were checked in (but not delivered) in the past 10 days were simply missing… Despite of the “Automatic Check-in policy” option (settable in the preferences of the RTC Eclipse Client) that I advised the team to use from the first day. This was a surprise. Possibly linked with the fact the sandbox was out-of-synch with the repository workspace for a while now. Or not.
We then got to article [2] that explains some good practices for recovering from a situation where you apparently lost some source content. We also checked blog post [3] which finished to provide with explanations for navigating the SCM history. As a result, we’ve checked the various approaches available:
- Eclipse’s Local History: unfortunately, it was N/A in our case (at least at the UI level) since component would fail to load up to completion.
- RTC Source Control’s Backup shed: was N/A in our case as this option needs to be activated beforehand (and is not the default).
- Check-in History (New in RTC 4.0): was not a solution to us as the last check-ins would not appear in this history.
Experimenting the rough way….
From there, I’ve wondered if we could directly access the Eclipse history (the same one we could not take benefit from Eclipse menus) folder. As a result, I found article [4] and located this folder :
<eclipse_workspace>/.metadata/.plugins/org.eclipse.core.resources/.history/
Reference articles / resources:
- [Eclipse.org] FAQ Where is the workspace local history stored?
Checking its content, it’s pretty ROUGH to parse by a human: files are disseminated in many folders, file names are unrecognizable… But we circumvented part of the problem by proceeding to a “Search in Files” from a text editor (like TextPad, Notepad++, etc.) using a filtering based on the Java Class names the intern knew he had made major changes for. Finally, he could retrieve the latest versions of the Java classes he had modified in the past days. Pffiouu…
Solved a problem for now but…
Again, this is pretty rough. But I found it interesting to share with the community in case you’d fall into this seldom situation where article [1] [2][3] could not apply to you. Consider it as being the LAST option to choose for recovering your latest source code. In all other situations, RTC provides a range of far more handy solutions depicted in the list of articles above.
… planning to identify and solve the core problem.
This intern now smoothly accepts and delivers change sets in RTC again. Though this is not completely satisfactory. We miss the root cause of the initial problem (Eclipse-sided or different ?). Stay tuned as I shall update this blog post when it is properly identified.
Stephane Leroy's Blog 
Leave a comment