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.
Summary: | CVS status of files not updated after using external CVS command | ||
---|---|---|---|
Product: | versioncontrol | Reporter: | Jesse Glick <jglick> |
Component: | CVS | Assignee: | issues@versioncontrol <issues> |
Status: | NEW --- | ||
Severity: | blocker | CC: | tbrunhoff |
Priority: | P2 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
Jesse Glick
2005-08-11 21:57:18 UTC
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. |