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.

Bug 62182 - CVS status of files not updated after using external CVS command
Summary: CVS status of files not updated after using external CVS command
Status: NEW
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: CVS (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: issues@versioncontrol
Depends on:
Reported: 2005-08-11 21:57 UTC by Jesse Glick
Modified: 2014-10-25 14:01 UTC (History)
1 user (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-08-11 21:57:18 UTC
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.)
Comment 1 Maros Sandor 2005-08-11 23:17:39 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.
Comment 2 Jesse Glick 2005-08-11 23:30:38 UTC
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.
Comment 3 Jesse Glick 2005-12-20 19:09:21 UTC
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.)
Comment 4 tbrunhoff 2014-10-24 15:03:46 UTC
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
Comment 5 Jesse Glick 2014-10-25 14:01:59 UTC
tbrunhoff: better to file a separate bug report.