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.
Dev build. I have some CVS-controlled project open. I make some modifications to a couple of files, and Show Project Changes shows them as modified, fine. For whatever reason, I then go to a shell and commit them using the command line (or PCL-CVS from Emacs). I switch back to NetBeans, and switch to these files in the editor and even focus the Versioning window, but the IDE still shows them as locally modified (in the Versioning window, and by using blue color). I need to click the Refresh button (and contact the server) just for the IDE to notice that the changes were already committed. I think the IDE could do a better job of noticing external CVS actions. After all, it notices if I have deleted or modified a file on disk and closes or reloads the editor window correspondingly, and if a file was added on disk to a visible folder, it appears automatically after a moment. That lets me get right back to work. All cvslite needs to do is at some point notice that the CVS/Entries files on disk do not match whatever it last saw. Note that there is already a background task which runs whenever the IDE main window gets focus that checks for disk changes in loaded FileObject's. And that is all I care about - files which are open in the editor, visible in the explorer, etc. It would be nice to also check whenever the Versioning window is given focus whether any of the displayed entries in it are out of date according to CVS/Entries timestamp information. This is similar to the behavior of the editor window in checking for external modifications in the open file when it is given focus, even without a full filesystem refresh. All this should be possible to do rather fast, without contacting the server, and would save the user the effort of manually refreshing the Versioning view after using an external CVS tool. (A complete local disk scan, a la PCL-CVS's M-x cvs-quickdir, would be too expensive on a large source tree to run without the user's consent.)
Nice idea. However, the problem is that file modification evets are only fired for already existing FileObjects. CVS/Entries is almost never constructed as a FileObject and even if it were, it would not be frequently visible in the GUI (thus would be collected soon). I cannot keep strong references to Entries either. We would need a global (native) filesystem listener for this to work I think. Can you think of some feasible solution? If I were notified of Entries being modified I would be able to act accordingly.
Maybe cvslite could keep a WeakHashMap whose keys are folders $path and whose values are the FileObject for $path/CVS/Entries. That would cause masterfs to hold onto the Entries for as long as the parent folder existed, meaning you would get notified of changes after a global refresh (I hope), yet not make for a real memory leak. You would still have to manually check for changes in other cases, like the Versioning window or the editor for a versioned file getting focus.
For me this is the most significant problem with javacvs today. Other than this issue it is pleasant to use and usually works politely with command-line CVS. (With the exception that folders created or deleted from the IDE must also be committed from the IDE since the on-disk metadata is wrong. But that is probably not solvable given the working dir format used by the CVS and the design constraints of javacvs.)
Found this bug which has been lying around for about a decade, and its still a problem! Originally reported for cvs, I've changed it to subversion. We have some very large subversion repositories, and frequently I find I need to use the subversion cli to update, check in, etc. In my case: - modify a file in NB; the file name changes from black to blue, and the diff marks appear in the right column. - check in the file using svn cli - NB updates the diff marks in the right column, but leaves the file marked in blue. - select update-->HEAD and the file name changes from blue to black. Product Version: NetBeans IDE Dev (Build 201409241121) Updates: Updates available Java: 1.7.0_45; Java HotSpot(TM) Client VM 24.45-b08 Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b18 System: Linux version 3.12.6-200.fc19.x86_64 running on i386; UTF-8; en_US (nb) User directory: /home/toddb/.netbeans/dev Cache directory: /home/toddb/.cache/netbeans/dev
tbrunhoff: better to file a separate bug report.