This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
We are still seeing circumstances when doing a CVS -> Update that are causing us to lose work. The problem occurs when the file that needs to be merged is open in the source editor window. The scenarios are as follows: Scenario 1 (partially witnessed) ================================ User A makes a change to a text file (in our case, a large text file of approx. 500 Kb) and commits. User B has the changed their working copy version of the same file locally AND has the file open in the source editor window. User B then does a CVS -> Update (update -d - P). NetBeans javacvs reports that a merge has ocurred and it DOES do the merge in the file on disk, but User B's copy of the file loaded in the source editor buffer is not updated with the change. (This part of Scenario 1 is speculation AS we didn't explicitly witness the buffer not getting updated, but we haven't been able to explain by any other means) User B then makes a change to the file in the source editor buffer, saves the file, and commits. User A's changes are lost and User B's version of the file is now the HEAD. Scenario 2 (fully witnessed) ============================ User A makes a change to a text file (in our case, a large text file of approx. 500 Kb) and commits. User B has changed their working copy version of the same file locally AND has the file open in the source editor window. User B then does a CVS -> Update (update -d - P). NetBeans javacvs reports that a *conflict* has ocurred. The conflict DOES show in the file as it is stored ON DISK, but User B's copy of the file loaded in the source editor buffer is not updated with the conflict. User B is clueless as to why NetBeans just reported a conflict but did not show the conflict in the source editor buffer. I will hopefully be attaching some snapshots of the problem to help in diagnosis. Also, we have previously reported problems along these lines in bug 32540, but those issues appear to have been fixed in 3.5. This is a new issue. Thanks for the help!
Created attachment 11611 [details] The file in NetBeans that had a conflict, but did not show the conflict in the buffer
Created attachment 11612 [details] A windows DIFF utility that shows the conflict in the file on disk (left)
Another thing that may or may not matter is that during scenario 2 I had the file in question split into to editor panes (by cloning the view and then redocking the cloned view into the bottom of the source editor pane). I don't think this matters, however, as we have seen scenario 1 occur without the window being split, but I just thought I would pass along.
According to issue #29688 this should had been already fixed. Maybe there's something more missing. I'll try to reproduce it...
O.K., now I understand (I hope) how this happens. It's true, that the editor buffer is not reloaded even after the content of the file is changed by the update. The updated files should be refreshed to communicate the updated state to the Editor. However, this is not sufficient. The update can take some time, and the user can modify the file in between! It's necessary to lock all files that are to be updated to prevent their modifications in the IDE. After the update is finished, the files can be refreshed and unlocked.
The problem with refreshes after updates is not a problem of missing refresh, but of a time resolution. On Solaris (and probably most other operating systems) the file modification time is stored with a precission rounded to the nearest second. Thus if you save & update the file in less then a second, the file modification time does not change even though the file content is changed. An easy fix seems to be: when a save operation is performed automatically before the update command, wait for a second after the save finish before update command is executed. This will delay the update, but will hopefully solve the problem.
The first part is fixed in the main trunk: Checking in FileSystemCommand.java; /cvs/javacvs/src/org/netbeans/modules/javacvs/commands/FileSystemCommand.java,v <-- FileSystemCommand.java new revision: 1.28; previous revision: 1.27 done Checking in VcsAction.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/VcsAction.java,v <-- VcsAction.java new revision: 1.78; previous revision: 1.77 done And projects branch: Checking in VcsAction.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/VcsAction.java,v <-- VcsAction.java new revision: 1.72.4.5; previous revision: 1.72.4.4 done So, if there is any file automatically saved before the update is executed, we delay the update by one second. Now we should lock all files, that are being updated so that they can not be modified concurrently in the IDE.
The second problem is fixed for JavaCVS in the main trunk. Now it's impossible to modify files in the IDE while update command is running on them. Checking in commands/CacheUpdatingFsCommand.java; /cvs/javacvs/src/org/netbeans/modules/javacvs/commands/CacheUpdatingFsCommand.java,v <-- CacheUpdatingFsCommand.java new revision: 1.33; previous revision: 1.32 done Checking in commands/CvsUpdate.java; /cvs/javacvs/src/org/netbeans/modules/javacvs/commands/CvsUpdate.java,v <-- CvsUpdate.java new revision: 1.11; previous revision: 1.10 done Checking in commands/FileSystemCommand.java; /cvs/javacvs/src/org/netbeans/modules/javacvs/commands/FileSystemCommand.java,v <-- FileSystemCommand.java new revision: 1.29; previous revision: 1.28 done Checking in Bundle.properties; /cvs/javacvs/src/org/netbeans/modules/javacvs/Bundle.properties,v <-- Bundle.properties new revision: 1.13; previous revision: 1.12 done Checking in JavaCvsFileSystem.java; /cvs/javacvs/src/org/netbeans/modules/javacvs/JavaCvsFileSystem.java,v <-- JavaCvsFileSystem.java new revision: 1.94; previous revision: 1.93 done Issue #36113 was filled for command-line VCS filesystem (vcscore module).
OK for JavaCVS in dev build #200309300100