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.
Category: versioning Component:diff (there was no diff under versioncontrol) I use solstudio (dev version) to browse my current Hg deltas of C++ code. I do such browsings frequently. Certainly before I commit, in order to write up my integration-notes, but also while I'm working on a feature or bug. I other words I use diff a lot. And that's about all I use solstudio for. But I don't use solstudio to edit my code; I use 'vi' externally. So I depend on NB's editor syncing. When I review my deltas I just click the [Next Diff] button. It turns out however, that just getting to the next file might not provide an up-to-date view of the file. One has to click in the editor view to sync up the view with what's on disk. This really doesn't make for good flow for the task of browsing your diffs. I'd like to be able to keep my mouse pointer on the next button and just click it and be assured of reliable information. There's one additional gotcha in that after the file has been synced it (sometimes?) jumps to the end of the file and have to manually switch to the first diff.
I'd like to make a plea for this (and companion Bug 211190) to be fixed. I heavily depend on diff functionality. I review changes several times a day.
i was able to reproduce the reported problem also on mac, but not on linux. it looks like no change event is not triggered by the fs watcher. the reason why it worked in case the diff editor is that nbeditorui has a focus listener set on the component and explicitely refreshes the FO. status refresh doens't work on external change as well (no change event delivered fo vcsfsinterceptor)
I don't have Mac to solve anything Mac related. Anyway native listening on Mac is implemented by Tomáš Zezula. As far as I know the native FS watcher has been disabled on Solaris by CND guys. To have some idea of what is going on in the system, you can turn logging on: -J-Dorg.netbeans.modules.masterfs.watcher.level=FINE You can disable native watcher completely on any system: -J-Dorg.netbeans.modules.masterfs.watcher.disable=true (so you can simulate the behaviour of diff window on Solaris on any system). Turning on: -J-Dorg.netbeans.core.ui.focus.level=FINE will tell us what the "manual" on focus refresh is doing. Anyway, if you believe diff view should always be up to date with disk, you can do the same thing editor does - check the time stamp on an click or other important event.
You can use -J-Dorg.netbeans.modules.masterfs.watcher.FAM=true to turn the Solaris native watcher on.
(In reply to comment #4) > You can use > -J-Dorg.netbeans.modules.masterfs.watcher.FAM=true > to turn the Solaris native watcher on. thanks jarda. ivan, could you please verify if the switch works for you?
The mac part works fine (the event was delivered) as we verified with Tomas S.. If it does not work on Mac it's an apparent problem in masters.
(In reply to comment #6) > The mac part works fine (the event was delivered) as we verified with Tomas S.. > If it does not work on Mac it's an apparent problem in masters. How it can be apparent problem in masterfs when the event is delivered!?
>How it can be apparent problem in masterfs when the event is delivered!? I am talking about the Mac specific part, the event was delivered by the OS X notifier to MasterFS not by MasterFS to listeners.
(In reply to comment #5) > (In reply to comment #4) > > You can use > > -J-Dorg.netbeans.modules.masterfs.watcher.FAM=true > > to turn the Solaris native watcher on. > thanks jarda. > > ivan, could you please verify if the switch works for you? Thanks for looking into this guys. FAM Doesn't seem to help. I turned on masterfs.watcher.level=FINE but there was nothing. I did notice INFO [org.netbeans.core.ui.focus]: External Changes Refresh on focus gain disabled which reminded me to turn on "Enable auto-scanning of sources". that didn't help either. I'm on Solaris 10 and from what I've googled FAM isn't readily/by default available on S10. I had expected a solution along the lines of what Jarda suggested at the end of comment 3.
- the problem reported from mac in comment #2 turned out to be caused by files coming from a symlink folder, filed issue #212897 to track that down - another thing is that when trying to reproduce the solaris notifier via -J-Dorg.netbeans.modules.masterfs.watcher.disable=true i wasn't able to reproduce as well. Could it be that with that switch on the IDE falls back on some other refresh mechanism? > I had expected a solution along the lines of what Jarda suggested at > the end of comment 3. we shouldn't call it a solution. workaround fits better - in case we want to support external changes, the IDE should in the first place properly notify about them. On the other hand - this issue is quite a corner case (to use the IDE merely as a diff tool) and before we pollute the diff code base with an explicite fo refresh (which seems to be necessary only if the IDE is used like a difftool on solaris, where btw the native FS watcher was deliberately disabled), i would like you to check if -J-Dorg.netbeans.modules.masterfs.watcher.disable=true wouldn't eventually work also for you. thanks
(In reply to comment #10) Do you mean to say that with -J-Dorg.netbeans.modules.masterfs.watcher.disable=true things, paradoxically, worked for you? I tried it w/ and w/o "Enable auto-scanning of sources" and it didn't help.
(In reply to comment #11) > (In reply to comment #10) > Do you mean to say that with > -J-Dorg.netbeans.modules.masterfs.watcher.disable=true > things, paradoxically, worked for you? yes. > > I tried it w/ and w/o "Enable auto-scanning of sources" and it > didn't help.
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > Do you mean to say that with > > -J-Dorg.netbeans.modules.masterfs.watcher.disable=true > > things, paradoxically, worked for you? so did you try the switch or not?
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #10) > > > Do you mean to say that with > > > -J-Dorg.netbeans.modules.masterfs.watcher.disable=true > > > things, paradoxically, worked for you? > so did you try the switch or not? > I tried it w/ and w/o "Enable auto-scanning of sources" and it > didn't help.
> > so did you try the switch or not? > > I tried it w/ and w/o "Enable auto-scanning of sources" and it > > didn't help. so any update on this? afaik "Enable auto-scanning of sources" is a setting (i'm not quite sure what exactly it does) and i was talking about a cli switch. That are two different things and it would be great if you could confirm that you have tried the _switch_. thanks
(In reply to comment #15) > > > so did you try the switch or not? > > > > I tried it w/ and w/o "Enable auto-scanning of sources" and it > > > didn't help. > > so any update on this? afaik "Enable auto-scanning of sources" is a setting > (i'm not quite sure what exactly it does) and i was talking about a cli switch. > That are two different things and it would be great if you could confirm that > you have tried the _switch_. > > thanks I can only repeat my comment 11 again (this time with a slight modification): Do you mean to say that with -J-Dorg.netbeans.modules.masterfs.watcher.disable=true things, paradoxically, worked for you? I tried -J-Dorg.netbeans.modules.masterfs.watcher.disable=true w/ and w/o "Enable auto-scanning of sources" and -J-Dorg.netbeans.modules.masterfs.watcher.disable=true didn't help.
fixed in core-main #3f993cb3e55c
workaround available via -J-Dorg.netbeans.modules.diff.forceFORefresh=true
Integrated into 'main-golden', will be available in build *201206120719* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/3f993cb3e55c User: Tomas Stupka <tstupka@netbeans.org> Log: Issue #210834 - Shouldn't have to click to sync edit view when diffing
(In reply to comment #18) > workaround available via -J-Dorg.netbeans.modules.diff.forceFORefresh=true This doesn't seem to make a difference for me.
(In reply to comment #17) > fixed in core-main #3f993cb3e55c Tomas, just a small comment to pushed code. Boolean.getBoolean("org.netbeans.modules.diff.forceFORefresh") easier to read, comparing to "true".equals(System.getProperty("org.netbeans.modules.diff.forceFORefresh", "false"))
(In reply to comment #20) > (In reply to comment #18) > > workaround available via -J-Dorg.netbeans.modules.diff.forceFORefresh=true > > This doesn't seem to make a difference for me. Ivan, which build have you used?
(In reply to comment #22) > > > workaround available via -J-Dorg.netbeans.modules.diff.forceFORefresh=true > > > > This doesn't seem to make a difference for me. > Ivan, which build have you used? Some old one I don't understand. If there's a fix in a new build why a workaround in a new build?
(In reply to comment #23) > (In reply to comment #22) > > > > > workaround available via -J-Dorg.netbeans.modules.diff.forceFORefresh=true > > > > > > This doesn't seem to make a difference for me. > > Ivan, which build have you used? > > Some old one > I don't understand. > If there's a fix in a new build why a workaround in a new build? it is Q for Tomas why refresh is not called unconditionally, but only under flag... Probably he wants you to check first when running under flag, because refresh gives performance penalty?
(In reply to comment #23) > (In reply to comment #22) > > > > > workaround available via -J-Dorg.netbeans.modules.diff.forceFORefresh=true > > > > > > This doesn't seem to make a difference for me. > > Ivan, which build have you used? > > Some old one > I don't understand. > If there's a fix in a new build why a workaround in a new build? sorry for the confusion, perhaps shouldn't call it a workaround, but as a metter of fact, i consider the fix more a workaround then a solution. see also comment #10 for more arguing. please try a new build (comment #19)
> Boolean.getBoolean("org.netbeans.modules.diff.forceFORefresh") > easier to read, comparing to > "true".equals(System.getProperty("org.netbeans.modules.diff.forceFORefresh", > "false")) yes. thanks
> > If there's a fix in a new build why a workaround in a new build? > it is Q for Tomas why refresh is not called unconditionally, but only under > flag... Probably he wants you to check first when running under flag, because > refresh gives performance penalty? - probably no issue on a local disk, but might have an impact on slower filesystems. - for now it looks like the original problem is in the watcher being off. - to solve a rare (maybe even unique) corner case is no justification to potentially cause harm to a bigger group of users and i'm not willing to have the refresh on by default.
(In reply to comment #25) > sorry for the confusion, perhaps shouldn't call it a workaround, but as a > metter of fact, i consider the fix more a workaround then a solution. see also > comment #10 for more arguing. You mean that your fix _plus_ -J-Dorg.netbeans.modules.diff.forceFORefresh=true will get me going?
(In reply to comment #27) > > > If there's a fix in a new build why a workaround in a new build? > > it is Q for Tomas why refresh is not called unconditionally, but only under > > flag... Probably he wants you to check first when running under flag, because > > refresh gives performance penalty? > - probably no issue on a local disk, but might have an impact on slower > filesystems. > - for now it looks like the original problem is in the watcher being off. > - to solve a rare (maybe even unique) corner case is no justification to > potentially cause harm to a bigger group of users and i'm not willing to have > the refresh on by default. Tomas, if Ivan confirms that your "fix" under flag works then I propose to change logic to use boolean manual = NbPreferences.root().node("org/openide/actions/FileSystemRefreshAction").getBoolean("manual", false); // NOI18N instead of dedicated flag.
(In reply to comment #28) > (In reply to comment #25) > > > sorry for the confusion, perhaps shouldn't call it a workaround, but as a > > metter of fact, i consider the fix more a workaround then a solution. see also > > comment #10 for more arguing. > > You mean that your fix _plus_ -J-Dorg.netbeans.modules.diff.forceFORefresh=true > will get me going? i hope so
> change logic to use > boolean manual = >NbPreferences.root().node("org/openide/actions/FileSystemRefreshAction").getBoolean("manual"> false); // NOI18N > instead of dedicated flag. is that bound to some user setting? what is the default value?
(In reply to comment #31) > > change logic to use > > boolean manual = > >NbPreferences.root().node("org/openide/actions/FileSystemRefreshAction").getBoolean("manual"> false); // NOI18N > > instead of dedicated flag. > is that bound to some user setting? what is the default value? This is the current value of "Enable auto-scanning of sources" from Tools->Options->Misc->Files panel
"manual" 'true' means user turned off auto-scanning. Default state is "manual" 'false' (check box is checked)
(In reply to comment #33) > "manual" 'true' means user turned off auto-scanning. Default state is "manual" > 'false' (check box is checked) so disabling the autoscaning would activate the fo refresh and we could give up the switch. Nice but for one thing - the meaning of the check box is that "When selected, the IDE will scan the source code of projects to detect any files that were modified externally ... if your sources are only modified from within the IDE, you can probably disable auto-scanning". And that's the oposite to the reported scenario. is there a way how to find out that the (solaris) fs watcher is off? maybe that would be a suitable replacement for the switch ...
(In reply to comment #34) > is there a way how to find out that the (solaris) fs watcher is off? maybe that > would be a suitable replacement for the switch ... currently it is always off unless org.netbeans.modules.masterfs.watcher.FAM=true
(In reply to comment #32) > (In reply to comment #31) > > > change logic to use > > > boolean manual = > > >NbPreferences.root().node("org/openide/actions/FileSystemRefreshAction").getBoolean("manual"> false); // NOI18N > > > instead of dedicated flag. > > is that bound to some user setting? what is the default value? > This is the current value of "Enable auto-scanning of sources" from > Tools->Options->Misc->Files panel Vladimir, I'm not sure this is a good idea. FAM doesn't work on S10, and auto-scanning, particularly on focus change, is particularly nasty. I tend to in general to turn this auto-scanning off. Note tat choice of a platform (i.e. S10) in the native wolrd is not made on the base of features of that platform but based on the oldest platform that the native product is supposed to run on. I.e. S11 build apps typically don't run on S10 therefore constraining all development to be on S10 systems. This will be true for internal usage as well as customer usage.
(In reply to comment #30) > (In reply to comment #28) > > (In reply to comment #25) > > > > > sorry for the confusion, perhaps shouldn't call it a workaround, but as a > > > metter of fact, i consider the fix more a workaround then a solution. see also > > > comment #10 for more arguing. > > > > You mean that your fix _plus_ -J-Dorg.netbeans.modules.diff.forceFORefresh=true > > will get me going? > i hope so Vladimir, what would be the best way to get these new bits? As I wrote earlier to you the auto-update for SS-internal doesn't work well. I don't mind waiting for the next SS milestone release if Tomas wouldn't mind :-)
OK, I verified that with -J-Dorg.netbeans.modules.diff.forceFORefresh=true and ss b15 things work. Thanks.
I'm sorry, I just found out that it's not fixed after all. It's because the latest-and_greatest SS IDE (build 15) Oracle Internal IDE internal-oss-49-on-20120504 which I am using is actually older then the fixes here. So I'm moving the VERIFIED state back to CLOSED until I can verify it.
I think I have the right bits now. And the auto sync seems to be there. However, the following, from my initial description, is still an issue: > There's one additional gotcha in that after the file has been synced > it (sometimes?) jumps to the end of the file and have to manually switch > to the first diff.