Bug 210834 - Shouldn't have to click to sync edit view when diffing
Shouldn't have to click to sync edit view when diffing
Status: REOPENED
Product: utilities
Classification: Unclassified
Component: Diff
7.2
Sun Solaris
: P3 (vote)
: 7.2
Assigned To: Tomas Stupka
diff-issues@utilities
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-06 18:52 UTC by ivan
Modified: 2014-02-04 05:53 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ivan 2012-04-06 18:52:37 UTC
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.
Comment 1 ivan 2012-05-14 19:28:35 UTC
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.
Comment 2 Tomas Stupka 2012-05-22 15:05:04 UTC
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)
Comment 3 Jaroslav Tulach 2012-05-22 16:10:19 UTC
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.
Comment 4 Jaroslav Tulach 2012-05-22 16:20:40 UTC
You can use

-J-Dorg.netbeans.modules.masterfs.watcher.FAM=true 

to turn the Solaris native watcher on.
Comment 5 Tomas Stupka 2012-05-22 16:25:53 UTC
(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?
Comment 6 Tomas Zezula 2012-05-22 16:42:13 UTC
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.
Comment 7 Jaroslav Tulach 2012-05-22 16:45:13 UTC
(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!?
Comment 8 Tomas Zezula 2012-05-22 16:47:13 UTC
>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.
Comment 9 ivan 2012-05-22 19:22:36 UTC
(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.
Comment 10 Tomas Stupka 2012-05-23 13:51:41 UTC
- 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
Comment 11 ivan 2012-05-23 20:33:45 UTC
(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.
Comment 12 Tomas Stupka 2012-05-23 20:41:23 UTC
(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.
Comment 13 Tomas Stupka 2012-05-25 07:00:03 UTC
(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?
Comment 14 ivan 2012-05-25 19:24:32 UTC
(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.
Comment 15 Tomas Stupka 2012-06-08 09:35:34 UTC
> > 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
Comment 16 ivan 2012-06-08 18:23:09 UTC
(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.
Comment 17 Tomas Stupka 2012-06-11 09:13:19 UTC
fixed in core-main #3f993cb3e55c
Comment 18 Tomas Stupka 2012-06-11 09:14:22 UTC
workaround available via -J-Dorg.netbeans.modules.diff.forceFORefresh=true
Comment 19 Quality Engineering 2012-06-12 13:15:29 UTC
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
Comment 20 ivan 2012-06-13 18:33:52 UTC
(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.
Comment 21 Vladimir Voskresensky 2012-06-13 19:23:04 UTC
(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"))
Comment 22 Vladimir Voskresensky 2012-06-13 19:24:00 UTC
(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?
Comment 23 ivan 2012-06-13 19:41:19 UTC
(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?
Comment 24 Vladimir Voskresensky 2012-06-13 19:45:06 UTC
(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?
Comment 25 Tomas Stupka 2012-06-14 06:38:59 UTC
(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)
Comment 26 Tomas Stupka 2012-06-14 06:41:53 UTC
> Boolean.getBoolean("org.netbeans.modules.diff.forceFORefresh")
> easier to read, comparing to
> "true".equals(System.getProperty("org.netbeans.modules.diff.forceFORefresh",
> "false"))
yes. thanks
Comment 27 Tomas Stupka 2012-06-14 06:51:22 UTC
> > 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.
Comment 28 ivan 2012-06-14 07:24:08 UTC
(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?
Comment 29 Vladimir Voskresensky 2012-06-14 07:35:19 UTC
(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.
Comment 30 Tomas Stupka 2012-06-14 07:38:20 UTC
(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
Comment 31 Tomas Stupka 2012-06-14 07:41:38 UTC
> 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?
Comment 32 Vladimir Voskresensky 2012-06-14 07:42:55 UTC
(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
Comment 33 Vladimir Voskresensky 2012-06-14 07:44:02 UTC
"manual" 'true' means user turned off auto-scanning. Default state is "manual" 'false' (check box is checked)
Comment 34 Tomas Stupka 2012-06-14 08:15:04 UTC
(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 ...
Comment 35 Egor Ushakov 2012-06-14 08:52:12 UTC
(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
Comment 36 ivan 2012-06-14 18:43:01 UTC
(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.
Comment 37 ivan 2012-06-14 18:45:08 UTC
(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 :-)
Comment 38 ivan 2012-07-02 22:38:30 UTC
OK, I verified that with 
-J-Dorg.netbeans.modules.diff.forceFORefresh=true
and ss b15 things work.

Thanks.
Comment 39 ivan 2012-07-04 22:26:44 UTC
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.
Comment 40 ivan 2012-07-05 23:45:00 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo