[ BUILD # : RC1 ]
[ JDK VERSION : 1.6.0 ]
See attachment ...
First I Refactor->Renamed some classes.
Because of mistake, one of those classes I Refactor->Renamed 2nd
After this, I had big problems:
- I got some messages like 'Cannot save' + 'file has externally
There was no way, to get rid of the asterix (modified file), so I
made backup copies externally, and repaired my workspace.
As I returned back to NetBeans, it recognized properly the external
changes, and all seems to be OK than.
Then I Refactor->Renamed a variable inside a class c2bIndexedMap -->
c2bPagedMap. The renaming was done, but again I got the described
At this point I created the 2 attached screenshots.
Note: Besides the described problems, the 2nd dialogue is a JOKE: Why
asking for overwrite, if there is no "Discard" button.
Maybe it's P1, because of dataloss.
Created attachment 72854 [details]
Created attachment 72855 [details]
Sorry, I mixed the order of the attached screenshots.
First was: *_2.jpg = "Can't save"
Second was: *_1.jpg = "Can't discard"
It looks as issue 149330 however it is different way how to get it. The only OK button is described in issue 150818.
I'm not able to reproduce it however it may be caused by the fact that my sources are not versioned (VCS). What VCS do
Could you try to reproduce with -J-Dorg.openide.text.level=100 and attach the log here -> INCOMPLETE for now
VCS = subversion 1.5.4
Created attachment 72921 [details]
Created attachment 72922 [details]
Created attachment 72923 [details]
Are you able to reproduce with non versioned files? Are you able to reproduce this with latest trunk build? I assume you
have files you refactor opened in editor.
Issue 150818 is about Bundle file ie. properties file. It is handled by different code not by CES/DES in
> Are you able to reproduce with non versioned files? Are you able to reproduce this with latest trunk build?
Maybe next days :-(
You are right, some, probably all, of the renamed classes had been open in editor at that time.
BTW: You can checkout the project here:
- I had renamed all *Indexed* to *Paged*
- In case of sun.nio.cs.US_ASCIIOffsetIndexedMapEncoder, I first erroneously renamed to US_ASCIIPagedIndexedMapEncoder,
and later to US_ASCIIOffsetPagedMapEncoder, which caused the issue.
- final result (after external repair): rev=471
It looks like duplicate of #149330. Please test with NB 6.5 FCS or latest trunk dev build. There should be no * after
I was able to reproduce with your project. The bug appears whenever you rename a class opened in editor two times
subsequently. However it seems that it is reproducible only on windows.
I can reproduce it with NB65 and trunk (200811251401)
subversion client on Windows is externally modifying java file after file is saved from editor. It is easy to reproduce
on Win XP.
1.Create local svn repo.
2.Create simple Java SE project with Main.java.
3.Import this project into svn repo.
4.Open Main.java in editor
5.Refactor->Rename Main.java (keep in the same package) eg. to a.java
6.Modify a.java in editor.
7.Save it. Dialog that file was modified externally appears.
It does not happen when file/project is not in svn repo. There was also bug in DataEditorSupport which caused incorrect
(original) file name was displayed in this dialog. I already fixed this as issue #154095 and changeset #d7a3a55ba8db.
Note: When I imported project to svn I selected default bundled svn client in IDE.
Note: You can repeat this as necessary. Just revert svn changes. Close new file in editor with Discard changes. Delete
new file created by rename. Open original file in editor, restart IDE and you can repeat with step 4. We debugged with
Jarda and there is no setLastSaveTime in code. Now CES/DES uses strictly file time stamp. You can use FileMon to find
out who touches file in question.
So bug is in Subversion client ?
the svn move command is changing a files timestamp. Unfortunately, the svn module has no control over it.
Is there any chance to refresh the timestamp value not only after a file change, but also after a rename?
Moving a file in Windows normally does not touch it's timestamp, also renaming.
So IMHO consider of a bug in SVN.
"expectedTime" event is used to update lastSaveTime in CES when fileRename event comes from file to DES. It handles case
when svn client externally changes file timestamp during rename (Refactor->Rename on file under svn).
it needs to be verified properly on different setups and different VCS.
I'm marking as candidate for patch 2 of NB65
Integrated into 'main-golden', will be available in build *200812030201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Marek Slama <firstname.lastname@example.org>
Log: #151787: Sync timestamp when svn client changes timestamp externally during rename.
*** Issue 153175 has been marked as a duplicate of this issue. ***
*** Issue 154402 has been marked as a duplicate of this issue. ***
*** Issue 155624 has been marked as a duplicate of this issue. ***
No Discard on "Overwrite externally modified file?"
After Refactor->Rename of a class, it did some editing on it.
Then I did "Save All" or "Run single Test" (Sorry, I don't remember), and got Warning instead of Error.
See Attachment ...
Created attachment 75347 [details]
No Discard on "Overwrite externally modified file?"
Sorry for error:
After OK, now I can see that I did Refactor->Rename of a variable, before I got the "Warning".
See next Attachment ...
Created attachment 75348 [details]
Refactor->Rename caused undiscardable "Warning"
Created attachment 75349 [details]
Cannot "Save All" after refactoring
I got rid of those messages by workaround:
File->Save As "MyClass.java.bak" :-)
The issue hasn't passed the nomination process for 65patch2 by cut-off date. It has been moved to 65patch3.
Please could you sum current status? Steps to reproduce? Again I assume you are on Win XP and your files are in svn repo.
Also part of IDE log with this exception would help.
Yes, I am on Win XP and my files are in svn repo:
Steps to reproduce?
It's too long time ago. I can't say more, than I had written.
The oldest log, I have, is from 6. Jan.
Created attachment 75827 [details]
I will try to play with renaming.
Closing. If anything like this happens again with latest dev build please file new issue and I will try to evaluate soon.
*** Issue 160029 has been marked as a duplicate of this issue. ***
*** Issue 151501 has been marked as a duplicate of this issue. ***