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.
org.netbeans.modules.vcscore.util.virtuals.VcsRefreshRequest schedules itself for periodic activity. Problem with _periodic_ background tasks is that these are not related to current users activity and degrade IDE responsiveness randomly. They can be replaced by batched asynchronous checks triggered by common actions related to original background task purpose.
Well, this must be some misunderstanding ?? VcsRefreshRequest was introduced as a replacement for org.openide.filesystems.RefreshRequest. It does the same thing plus can be used for extra priority refreshes. I'll consider removing it after org.openide.filesystems.RefreshRequest will be removed.
If openide fs SPI uses the same periodic check strategy then it introduces perfomance bug that need to be addressed. WONTFIX is not acceptable resolution until you have a proof that it does not cause performance problems.
O.K. ;-) Then I wonder how to resolve this. openide fs SPI introduce the exactly same performance problem. Thus I expect you to file a P2 bug on openide as well. I've heard some attempts to listen directly on the OS filesystem to know which files were added/removed/changed. This is IMHO the only solution, but OS-dependent. Thus I think, that this problem can be resolved only for some platforms, I'm afraid, that no generic and 100% pure Java solution exists.
Now I see what made you angry. It should be classified as task.
O.K. :-) But this really should be considered together with org.openide.filesystems.RefreshRequest. Will there be a similar task for openide? Then this task should depend on it and reuse it's solution.
Um, eeh, task and solution? For the case of LocalFileSystem (one of the users of RefreshRequest), I've solved it simply by setting the default refresh time to 0, which means no periodic refresh. Users/API clients can still enable the periodic refresh by setting the refreshTime property. RefreshRequest stays unmodified. You should use the same strategy for VCS filesystems, the goal is to have the IDE really idle when nobody is touching it (and is not instructed otherwise by the user).
O.K., then it's an easy "fix". Perhaps there should be something like "Refresh of local files" menu item introduced on VCS FS popup menu. Because CVS -> Refresh can take a long time. BTW: Is there a plan to implement some refresh process, that would listen on the OS filesystem? That would be the best fix (although for some platforms only).
In such case I would like to ask for HIE's opinion, because I personally don't like this approach. According to desired future direction of NetBeans I think that adding more menu items (= increasing IDE complexity) is not the right thing to do. Shouldn't we recover "Refresh" action that would search for local files and rename "CVS|Refresh" to "CVS|Refresh Status" or something ?
O.K., I'll just disable the periodic refresh by default.
Fixed in the main trunk for generic VcsFileSystem and JavaCvsFileSystem: /cvs/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v <-- VcsFileSystem.java new revision: 1.197; previous revision: 1.196 /cvs/javacvs/src/org/netbeans/modules/javacvs/JavaCvsFileSystem.java,v <-- JavaCvsFileSystem.java new revision: 1.88; previous revision: 1.87
Well I have to chime in on Martin side. For instance, when I have messed up a file and want to get the clean copy, I delete the file, then update it. But I have to wait for it to appear again before I can update it. Or I can run CVS refresh which takes long as Martin suggested. If you all gave me a regular refresh on a CVS folder then I could refresh it (quickly) myself, but their is no such option. I know folders are refreshed on first open, but they need to have a refresh on file delete as well right? maybe then my issue will disappear. Honestly, one does need some way to do a file refresh on a CVS folder. no!? Hope I am understing the issue correctly. I also do not like the background folder action I sometimes see. Heck personally I don't like the cvs action when I start the IDE or open the folder. If it is to be it should be up to me, as the saying goes. I probably didnt help much here :-}
No more background activity in idle IDE.
ClearCase does dynamic update. Without periodic refresh, the IDE will not be able to pick up changes made by the ClearCase filesystem. Therefore, at least for ClearCase, the period refresh should be on by default. Can periodic refresh be configure via the profile? Another alternative would be to add an menu action that let the user manually refresh the IDE.
What's dynamic update? I guess you have all files locally cached and you need to access remote repository only for updating file statuses. Periodic backgroud task does not guarantee nothing, it just statiscitaly decreases chance for inconsistency => code must be still aware of possible inconsistency.
Peter, please describe what is the impact, how this affect ClearCase users. It's not possible to configure the refresh from the profile. It's hard-coded to 0. However it's possible to change this in properties of the filesystem. From the performance poin of view it's generally forbidden to have periodic tasks.
In ClearCase, there is no update command similar to cvs. Depending on how the user configure his view profile, the ClearCase filesystem will automatically keep all files up-to-date. Without the periodic refresh, the IDE will never synch up with any changed files on disk. There is no other way for us to detect changed files. Just curious, since periodic refresh is not a good idea from a performance point of view, why don't we add at least a manual refresh command? Of course, I am not talking about the current status refresh command.
So, you need to emulate the CVS update (refresh) command. I think that you can move all logic presented in the planned background task to emulated update command implementation. Martin, VCS guru, what do you think?
I still do not understand why ClearCase -> Refresh is not enough. If there're some new files put by ClearCase after ClearCase -> Refresh you will see them together with the proper status. The periodic refresh works only for [Local] files, so you'll get the new files automatically with [Local] annotation which is probably not what do you want. So why ClearCase -> Refresh is not the correct action to use? > you can move all logic presented in the planned background task to > emulated update command implementation. Well, there is already enhancement #27735 for that.
Unless I am mistaken, the ClearCase->Refresh does not cause fileChanged events to be dispatched. It only updates the status of the files. Therefore, if a ClearCase updates the content of an existing file, the IDE will not know about it unless the period refresh is enabled. Petr is correct about what I have in mind. I think whatever logic being used in the periodic refresh should be exposed as an user action. Is enhancement 27735 going to be implemented for Nevada?
> Is enhancement 27735 going to be implemented for Nevada? No more enhancements are going to be implemented for Nevada. We've enough bugs to deal with. > ClearCase->Refresh does not cause fileChanged events to be > dispatched. Probably not. But if Refresh does not do that, the periodic refresh neither did it. You can test it yourself. You can enable the periodic refresh in filesystem properties (Expert tab, "Refresh Time For Local Files" property). ClearCase->Refresh does update file status, but also update newly created/deleted files on disk. So the work that periodic refresh did is a subset of what ClearCase->Refresh does. So my final question is: is there anything, that periodic refresh did and that can not be achieved with manual execution of ClearCase->Refresh?
BTW: enhancement #27735 is too invasive to be enabled by default. When the feature is implemented it could be enabled as an option, so this is similar to the periodic refresh of local files, which can be enabled as an option as well.
I agree that the periodic and manual refresh both detected newly created and deleted file. However, from my testing, the periodic refresh does detect modified files and causes fileChanged events to be dispatched whereas the manual refresh does not. Perhaps the periodic refresh also invokdes functionality provided by the AbstractFileSystem?
Just to clear something up. Clearcase dynamic views don't work anything like CVS. Think of an NFS volume mounted, not over another filesystem, but over a database query result set. Each read() call reexecutes the query over the repository. Martin's assessment seems correct: - polling is unacceptable - a true async filesystem notification mechanism is a long way off (e.g. JDK1.5/jsr203).
Resolving back as FIXED. This problem is fixed - periodic background activity is eliminated. See issue #32760 for the problem of context refresh action.
Okay.