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.
Summary: | Netbeans 3.4 Beta 2 CVS External Client does not Refresh correctly | ||
---|---|---|---|
Product: | obsolete | Reporter: | Ron Cordell <rcordell> |
Component: | vcscore | Assignee: | Martin Entlicher <mentlicher> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | mihmax, pkeegan |
Priority: | P3 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Ron Cordell
2002-07-04 13:56:57 UTC
Module vcscvs is no longer in NetBeans 3.4 therefore reassigning component. I must say that I've seen things like that too but can't reliably reproduce. :-( *** Issue 25543 has been marked as a duplicate of this issue. *** Any reproducible steps are needed. If this happens, please attach the content of CVS/netbeans.cmd.cache files located in parents of [Local] folders. Please mention also what did you do *before* this happened. Changing priority to P4 - manual refresh should always repair this. I think this should also be mentioned in the Release Notes of NetBeans 3.4. There are still some problems with incorrect status refreshing. Does this just happen with genericvcs? Or does it also happen with javacvs? In what kinds of situations does the problem occur? At first I thought that this issue only occurred with the external CVS client, but now I have seen it happen with the javacvs as well. I am unable to test with the generic cvs client. In such case this belongs to vcscore component. proposed release note: The automatic refresh of file status in version-controlled filesystems does not work correctly. Even if the Auto Refresh property for a filesystem is set to refresh files when a folder is opened, source files in that directory do not get refreshed (though files in subdirectories do get refreshed). Workaround: Manually refresh the folder using the either the Refresh or the Refresh Recursively command from the folder's submenu. I like it too, what do you think Martin ? It would always be a bit vague. Yes, it's good. It's important to mention that the workaround is to refresh the files manually. I'm not able to tell you the cause, I do not have reproducible steps. It happens quite rarely to me. Just to make sure: It's OK the way I stated it? Or does the user have to select the files individually before calling the Refresh command? Yes, it's O.K. the way you said it. Sorry for the confusion when I used the word "files", when I meant "refresh the files in the folder". The user would run the refresh on the affected folder of course. I'm increasing the priority to P3, since users are complaining about this on nbusers. Also if the fix will be available, it's a candidate for a 3.4.1 release if there will be any. I'm starting to explore the problem... Fixed in the main trunk. It's necessary to perform a recursive refresh to repair the disk cache, that can be in an inconsistent state. After the disk cache is repaired, it should stay consistent and statuses should be refreshed as expected. Checking in vcscore/src/org/netbeans/modules/vcscore/cache/CacheDir.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/cache/CacheDir.java,v <-- CacheDir.java new revision: 1.29; previous revision: 1.28 done Checking in vcscore/src/org/netbeans/modules/vcscore/cache/CacheFile.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/cache/CacheFile.java,v <-- CacheFile.java new revision: 1.9; previous revision: 1.8 done Processing log script arguments... More commits to come... Checking in vcscore/src/org/netbeans/modules/vcscore/caching/VcsCache.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCache.java,v <-- VcsCache.java new revision: 1.47; previous revision: 1.46 done Checking in vcscore/src/org/netbeans/modules/vcscore/caching/VcsCacheDir.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCacheDir.java,v <-- VcsCacheDir.java new revision: 1.39; previous revision: 1.38 done Checking in vcscore/src/org/netbeans/modules/vcscore/caching/VcsCacheFile.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCacheFile.java,v <-- VcsCacheFile.java new revision: 1.10; previous revision: 1.9 done Checking in vcscore/src/org/netbeans/modules/vcscore/caching/VcsFSCache.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsFSCache.java,v <-- VcsFSCache.java new revision: 1.32; previous revision: 1.31 done Processing log script arguments... More commits to come... Checking in javacvs/src/org/netbeans/modules/javacvs/caching/CvsCacheDir.java; /cvs/javacvs/src/org/netbeans/modules/javacvs/caching/CvsCacheDir.java,v <-- CvsCacheDir.java new revision: 1.27; previous revision: 1.26 done Checking in javacvs/src/org/netbeans/modules/javacvs/caching/CvsCacheFile.java; /cvs/javacvs/src/org/netbeans/modules/javacvs/caching/CvsCacheFile.java,v <-- CvsCacheFile.java new revision: 1.15; previous revision: 1.14 done Accepted for 3.4.1 Sincere, Maxym Martin, can you, please, QA this somehow? Okay, I'm gonna verify it soon Max. Well, this can be a problematic integration. This was a big change and I remember, that I've had to do some small touchups later. But definitely this bug is annoying and should be fixed in 3.4.1 IMHO. I would like to ask our QA (Jirka & Dan) to test the cache functionality really deeply in dev builds and report any problems. We could then merge the cache impl. from main trunk to 3.4.1 branch. Thanks. Well, this is really annoying, I agree. So you say that that's not only changes needed to fix this issue, (your comment on 2002-09-26 01:57 PDT)? > So you say that that's not only changes needed to fix this issue,
> (your comment on 2002-09-26 01:57 PDT)?
Yes. Some of them are additional fixes of reported bugs (e.g. issue
#27890), there is fixed one NPE, that was not reported and in addition
to this there is one performance fix, that can not be applied to 3.4.1
- issue #27239.
Thus I suppose, that we merge the changes reported here (comment on
2002-09-26 01:57 PDT) and then I'll manually merge additional fixes,
that are applicable (probably all except issue #27239). This should
not be a problem from QA point of view, since #27239 does not have any
affect on functionality.
Is that O.K.?
Yes, OK, I'll contact you, when the branch release341 is prepared (tagged from release34 branch). Maxym, we use Target Milestone to denote the version in which is the fix actually committed. So you should set the Target Milestone to 3.4.1 *after* it's committed to release341 branch. Otherwise it would break the queries and it will be considered as already fixed in 3.4.1 while it is not yet. So, if you don't mind, I'm changing the TM back to 4.0, we should change it to 3.4.1 as soon as it's fixed there. Thanks. Sorry, I think we surely need some "HOWTO work with IssueZilla (for naive Project Owners)" ;-) Well, this bug is very hard to verify but I agree that cache is more stable now. Problems that I discovered were usually of incorrect parser behaviour so I am verifying this issue in development build #200211140100 of NetBeans 4.0 and recommend it for NetBeans 3.4.1 release. Hi. This issue is marked as 3.4.1_CANDIDATE. It means that it should be integrated into release341 one branch. The plan at http://www.netbeans.org/devhome/docs/releases/34/index.html expected beta1 to be produced on Dec01. That did not happen due to a lot of outstanding not integrated candidates like this one. Would it be possible to spend few minutes by backporting this fix? Thank you in advance. I have tried the last two 3.4.1 dev builds. The one from 28 Nov seemed pretty good in this regard. The one from 2nd Dec seems to be worse. After starting NetBeans some folders and their contents are reported as [Local] even though they are not. A CVS Update does fix this. I have the impression (though not really verified it with testing) that this has happens when the initial display in the explorer is the project tab. The links to directories do not seem to behave correctly here (some of them disable the "Refresh" item, although that should be there all the times) The 3.4.1 dev build from 3.12. is far better now. It seems that the cache needs some "tune-in-time" :-) After I deleted all NB-CVS cache files and restarted it seems quite OK. I have been working with that build the whole day now, and have only once seen a wrong version display (but that was right after the first start after installing the build). But I do see situations where the title in the source editor's tab is not updated (i.e. when I commit, the tab text doesn't switch to the correct annotation). Merged into release341 branch. /cvs/vcscore/src/org/netbeans/modules/vcscore/cache/CacheDir.java,v <-- CacheDir.java new revision: 1.27.8.1.4.1; previous revision: 1.27.8.1 /cvs/vcscore/src/org/netbeans/modules/vcscore/cache/CacheFile.java,v <-- CacheFile.java new revision: 1.8.28.1; previous revision: 1.8 /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCache.java,v <-- VcsCache.java new revision: 1.46.28.1; previous revision: 1.46 /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCacheDir.java,v <-- VcsCacheDir.java new revision: 1.38.28.1; previous revision: 1.38 /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCacheFile.java,v <-- VcsCacheFile.java new revision: 1.9.28.1; previous revision: 1.9 /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsFSCache.java,v <-- VcsFSCache.java new revision: 1.31.30.1; previous revision: 1.31 /cvs/javacvs/src/org/netbeans/modules/javacvs/caching/CvsCacheDir.java,v <-- CvsCacheDir.java new revision: 1.26.28.1; previous revision: 1.26 /cvs/javacvs/src/org/netbeans/modules/javacvs/caching/CvsCacheFile.java,v <-- CvsCacheFile.java new revision: 1.14.34.1; previous revision: 1.14 Thomas, thanks for your tests, now the cache functionality in 3.4.1 should be stable. removing RELNOTE keyword since this was fixed for 3.41 Resolved for 3.4.x or earlier, no new info since then -> closing. |