Community
Participate
Working Groups
Using I20090929-0800: 1. I have an Eclipse project checked out from CVS, 2. I make some source changes, 3. I delete the project and check "Delete project contents on disk..." 4. I freshly check out the same project from the same CVS 5. I open the file I previously modified and observe my deleted change is still there I tried the same for a Java file on the source path and for another resource (e.g., an about.html). Only the Java source shows this behavior, which makes me think of Java model caching, but is that caching the source chars, too? The file system has the correct file contents. Note that for step 5 I used the Open Type dialog. I could observe (once) that a file opened via double click in the package explorer contained the fresh source as found on disk, but closing the undead source file and open it from the package explorer did not refresh it. Not even the refresh action helped. Hm, undead source files getting ready for Halloween? ;-)
Restarting Eclipse finally lets my deleted changes rest in peace..
I tried to reproduce, but unsuccessfully. I must miss something in the steps to reproduce.
Jay, please investigate. We need to understand what is going on. Please talk with Stephan to find steps to reproduce. Targeting 3.6M4 as we are getting close to M3.
I just re-checked: on the affected workspace the bug still "works", i.e., it is reproducable. I don't think the steps are the problem for reproducing but more likely something in the enrivonment is. FWIW: I was using a plain vanille Eclipse SDK I20090929-0800, with no other plugins installed. One more detail: I used "check out as.." but stepped through the wizard without making changes. I was working with org.eclipse.jdt.core.tests.model and the class in question was JavaSearchTests. Although all operations involved some rebuilding/re-indexing it doesn't appear to be a timing issue, I let the machine calm down and even hit the garbage can before proceeding, still seeing my undead change after checkout. Jay, should you have any ideas for experiments I should make or files to send I'll be happy to do so. For my part I'm so amazed about this bug, I currently have no idea what to try next.
Some more results from experiments: - Compare with Latest from HEAD -> No changes found => must be using content from file - Search for references to a method used in JavaSearchTests: -> double click in the search result highlights the method call with an offset that corresponds to the length of my change. => positions must be using the (correct) file content display in the editor uses the cached (wrong) content - mark occurrences in the editor is consistent, no offset observed => must be consistently using the (wrong) cached content
I tried on my windows machine and unable to reproduce the bug. I will try to set-it up with a Linux environment also. Stephan, what about the outline view? Does it show the things you added, in case you added a method or field?
(In reply to comment #6) > Stephan, what about the outline view? Does it show the things you added, in > case you added a method or field? "Bad news": as I tried it today, I could no longer reproduce. I used that workspace yesterday for some debugging, checked out another project from CVS and prepared a patch. Likely that one of these actions brought the workspace back into a sound state, which could mean it was actually something in the workspace (vs. OS or other bits from the environment). As to the kind of change: I don't exactly recall the original scenario, I think it was changes in method bodies. In all the experiments for this report I was just adding a word to a doc comment. The first thing I tried today was adding a field, from where on I could no longer reproduce, neither way. At this point I wouldn't mind to close this as WORKSFORME and I will keep an eye on that workspace if it does me the favor of showing ghost changes again ...
You can reopen the bug if you run into the problem again.
Just logging a similar occurrence of what *could* be the same bug: - same machine - different workspace - different set of plugins installed - tried svn switch on project "P" which had local changes in P/src/SomeClass.java - subversive screwed up so "P" was unusable - renamed "P" to "P_BROKEN" - freshly checked out "P" from SVN - P/src/SomeClass.java still showed the local changes although it should be a pristine fresh checkout. - closed both projects - opened P only - opened P/src/SomeClass.java, still contained local changes, - compare with latest from repository: no differences - add a blank to P/src/SomeClass.java and save - compare with latest from repository: the local changes show up - at this point the bug can no longer be analyzed :( not opening the bug because I have no idea whether this is reproducible in any way, *sigh* note that the previous occurrence involved CVS while this involves SVN.
Verified for 3.6M4 using build I20091207-1800.
