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.
this issue is extract of the "big" one, issue #39817 , about ocasional [Local] statuses. But THIS always happens if you "add to Project" second level nested subfolder into Project Tab or if you mount it "as new FS" (using treeFSview) module. 100% Reproduction: =================== 1) mount new CVS FS (empty working) 2) checkout eg "diff" module from cvs.netbeans.org 3) expand nodes: diff | api 4) "add to Project" the "api" node. and collapse the root of CVS FS. 5) restart ide 6) In Project TAB if you expand "api" node the doc node and all other subnodes will be [local] 7) Switch to FS TAB and expand CVS FS root node. Imediately (within 1-2sec) all nodes change from [local] to [up-to-date]. 8) Switch back to ProjTaB... now all nodes in it became [up-to-date] too. This is IMHO problem of notifications, not cache (which is the issue #39817 about)
Oups.... Because it is an extract of P2 bug. And it is 100% reproductable this shoudl be mark as high priority bug too, IMHO. So, this annoying part of main bug will be fixed into NB36 (RC2?)
Yes Dane, I definetely agree. BTW, what's the current status of fixing effort Martine ? Are you working on this ?
Well, we've discused it with developers and we agreed that it is not real P2 bug. Both Projects tab and subFSs currently do not seem to be used that widely, and an easy workaround to the problem exists. It will need to be fixed in the next version though.
O.K. So I'm scheduling this for promotion D. Also I'm making this dependent on the cache redesign issue #32089. This usecase needs to be taken into account in the redesign.
Considering that users are complaining about this issue a lot, I've made a fix of this in trunk. After first tests the fix seems to work fine: /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCache.java,v <-- VcsCache.java new revision: 1.62; previous revision: 1.61
Created attachment 14240 [details] The binary patch that fix this problem.
To apply the binary patch: In the NetBeans installation directory, navigate into netbeans/modules/autoload directory and create "patches" directory there. In "patches" create "org-netbeans-modules-vcscore" directory and put "patch41424.jar" into it. Start NetBeans and verify in ide.log, that the patch was applied.
Created attachment 14241 [details] The contextual diff of the fix.
Patch applied and verified in ide.log. I am testing by starting NB without expanding any nodes in Filesystems tab. Using the userdir and project I created the use case with, CVS status is correct. In my production userdir, I find that if I close NB with the Filesystems tab showing, CVS status in Projects tab is correct after restart, but if I close NB with the Projects tab showing, then I still show [Local] after restart. Reproducible across many restarts. Root dir of Filesystems tab is /java; top dir in Projects is /java/com/weycogroup/slm.
Yes, we know about this tiny remainder and Martin is tracing it. I am ready to stay here tonight to verify the full fix. I hope he will find it though ...
Created attachment 14246 [details] A new binary patch.
It was found by QE, that the first binary patch does not fully fix the problem. The second binary patch should address that. It assures that the status information is read in all cases.
Looks really promising. No regression found so far. What do you think Glenn ?
New patch tested against both 3.6rc1 and 3.6rc2. No problems found. Thank you so much for fixing this, projects in 3.6 are once more usable for me!
I have been testing this fix two hours straight and found neither quality nor performance regression. I am attaching snapshot of CPU consumption with and without the second patch. It is obvious that it has almost no impact on startup time.
Created attachment 14247 [details] Snapshot of CPU consumption while IDE was starting up.
Cannot reproduce the problem anymore rc1. Gentoo Linux 2.6. Java 1.4.2.
Created attachment 14248 [details] The new contextual diff.
Patch reviewed without objections.
I've just verified the new binary patch. It solves successfuly all problems in Project TAB or mounted subFSs. I'm just connected via GPRS, so my connection is now pretty slower then in work. And Refresh realy connects to pserver which means it lasts very long time or it simply fails (if I'm disconected in this case... you've got, at IDE startup, IMHO unfrendly welcome in shape of Error Output of Refresh command which is not nice). But this mentioned tiny shadow, doesn't mean that fix is not solving problem properly. Even if Refresh fails then statuses became read from cache and are usualy [up-to-date] or in the same state before you exit ide.
Adding [36cat] prefix since this defect was found as part of NetCAT program.
*** Issue 40806 has been marked as a duplicate of this issue. ***
I am upgrading priority of this defect since it was independently reported by community and at least 5 NetCAT program members. This workflow is very frequent and in terms of impact on common user this issue represents a showstopper for NetBeans 3.6 release. Please integrate the fix into release36 banch.
Thanks for intensive tests and review, the fix is committed into trunk for now, I'll integrate it to release36 branch later today. /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCache.java,v <-- VcsCache.java new revision: 1.63; previous revision: 1.62
The fix is integrated in release36 branch: Checking in org/netbeans/modules/vcscore/caching/VcsCache.java; /shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCache.java,v <-- VcsCache.java new revision: 1.61.18.1; previous revision: 1.61
Verified in NetBeans 3.6
I see the following behavior in NB 4.0 final on Mac OS X 10.3.9: Files that are indeed mounted as CVS still show up with [Local] in the Project and Files view sometimes, but not other times. I can right-click and do cvs status on the file and that works fine, so I know I have it mounted up correctly.
edburns, this issue was about some particular case, which was reproducible. That case was fixed here. It does not mean that it works right in all cases, though. The caching framework was rewritten into 4.1, therefore all bugs like this should also disappear in 4.1.
Was already verified.
(See issue #32089).