Community
Participate
Working Groups
Build Identifier: 20100617-1415 I've triple checked this to make sure it wasn't a problem with my search/replace operation because it seemed quite unbelievable to me, but replacing "new Frequency" with "Frequency.every" in hundreds of files resulted in mangled replacement text in many of the replacement locations. I get Frequency.everyry, Frequency.everyvery, and others. And trying to file replace the mistakes to correct them just made the problem worse so I had to manually fix each file. Reproducible: Always Steps to Reproduce: 1. Take a source tree 2. Replace text 3. Notice horrible mistakes :) If this doesn't repro, happy to provide more details...
I can only assume what happened given the sparse information: I suspect that in your workspace several Eclipse resources are pointing to identical physical files or folders. While this is a valid setup for more complicated projects, you have to be aware that Eclipse is resource based and hence if you do a search it will find the match for all Eclipse resources e.g. if you search for "test" in project A: A f1 -> c:\foo.txt (with "test" in it) f2 -> c:\foo.txt (with "test" in it) ==> will find two matches: /A/f1 and /A/f2. This is the intended behavior which we won't change but obviously we should not corrupt any files. When replacing text in a bunch of files we should be smarter and remember which physical resource we already modified. Is that your setup?
*** Bug 303715 has been marked as a duplicate of this bug. ***
yes, but i'm afraid that is a fairly typical setup these days. on any decent sized project, you have nested maven projects and you have to have the root in your workspace too (to export patches from and commit from, mostly). i've been wanting for a long time to exclude the root project from all search and replace operations (i always get duplicates whenever i search my workspace). or even better: couldn't search determine the set of unique physical resources to operate on so it doesn't do things twice? it's definitely what i would expect as a user.
>better: couldn't search determine the set of unique physical resources to >operate on so it doesn't do things twice? No, that's not an option. You could use working sets for search.
Fixed in HEAD (ReplaceRefactoring.java, rev. 1.8). Available in builds >= N20110318-2000.
The fix caused a regression, see bug . The correct fix is in ReplaceRefactoring.java, rev. 1.9. Available in builds >= N20110415-2000.
Verified for 3.7M7 with I20110425-1800.
*** Bug 345754 has been marked as a duplicate of this bug. ***
The regression was bug 342932. And in 3.7 RC1, bug 343821 fixed a UI problem in the Search view.
