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.
[ JDK VERSION : J2SE 1.4.2_02 ] Several times I have seen that the status of CVS files is not refreshed; some files show as [Local]. After finishing some work on a project, I used the Find dialog to search for files with status LMod, ant got no results. The CVS refresh command is missing from context menu in project pane; in fact, going back to the explorer pane, I see that the directory mounted in project pane is marked [Local]. Selecting CVS refresh on parent directory in explorer pane returns things to normal. NetBeans 3.6 beta 1, Linux 2.4.20.
This looks like the same problem, which is described in issue #32193. The problem can be, that *sometimes* the status is dropped from the file status caching system. Do you encounter this problem often? It should be solved by issue #32089, which is too big to be done in 3.6 release.
Quite often. I would vote against releasing it like this, user must be able to trust version control. I've seen it on a 3.5 upgrade as well as a fresh install (no userdir upgrade). Sometimes it's a whole series of directories or files, sometimes just one. Let me know if there's any additional information I can send that would help diagnose it.
Well, it surprises me that this happens quite often to you. To me it happens very rarely therefore I didn't consider this as a big issue. I use the NetBeans CVS support in regular development and the status information is just fine. It would help to know usecases which lead to high probablity of broken statii. That can help to find the reason why it actually breaks.
I started a discussion about this on the NetCAT mailing list, and three of the four people who responded say they're experiencing it. Unfortunately, none of us can find a use case that will predictably trigger it... I'll keep trying.
Glenn, it would be really cool if you find any reliable repro-case ! This is a long lasting problem in cache consistency.
I experience this problem too. I never had this problem with 3.5.1 but with 3.6 Beta it is a daily problem. I think looking at the differences in the way 3.6 handles CVS versus the way 3.5.1 did is the key. This has to be fixed in the 3.6 final version - otherwise we will have to go back to 3.5.1. Randahl
Martin, can you reconsider the fix introducing certain performance degradation ? How much time does it cost ?
The file status caching system deserves a complete rewrite (see issue #32089). I'm going to explore the I/O part where it likely happens that some information is lost...
I have removed the optimization of cache file storage mechanism, that likely cause the status loss. -J-Dnetbeans.vcs.optimizedcache=true can be specified to use the optimization again for comparison reasons. The non-optimized approach should be more reliable and does not seem to cause big performance degradation, therefore it is the default. Since I was not able to reproduce the problem, I'm not able to verify whether this really helps. Therefore please let me know whether it's better after the "fix". It should be present in dev build #200402191900. /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCacheDir.java,v <-- VcsCacheDir.java new revision: 1.48; previous revision: 1.47 /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCacheFile.java,v <-- VcsCacheFile.java new revision: 1.17; previous revision: 1.16
I am still seeing this bug in build 200402191900, both with an updated userdir and with a fresh one. It appears in both the explorer and the projects pane.
Is there any chance that this might have to do with deleting the files starting with ".#" (which I do regularly)?
This bug is not yet fixed - several of the users still see this. I am seeing it all the time with build 200402251620 has it been fixed in the trunk?
Yes, it was "fixed" in trunk. The build 200402251620 which you're using have this integrated. Since I'm not able to reproduce the problem, I could not verify whether the fix actually solves the problem or not. Since you're still seeing the problem it looks like the fix did not help at all. Therefore I'm reopening the issue. Also issue #40744 was fixed recently. It's possible that it has a positive effect on this issue.
It's possible, that this issue is connected with issue #40806. Do you use both Filesystems and Project tab? Is it possible that this bug occurs when the CVS filesystem is accessed from both tabs?
Generally I use only the project tab. I have a few files which are not accessible through my project tab, and I access those files through the filesystem tab; however, the error does not relate to those files. I experienced the bug with the original 3.6 beta, and right after installing the 200402251620 q-build I had a huge amount of folders and files which had improper CVS information - roughly 100 of my 1200 files I would say. What really concerns me the most is that there seems to be no pattern to which files are treated wrong - it seems completely random.
I am using a CVSNT server by the way. What about all other people experiencing this? - Is this also occuring when NetBeans communicates with other versions of CVS?
I use both Filesystems and Project tabs. Expanding Filesystems tab to the directory used for the project (typically three or four directories deep) almost always refreshes the CVS status as I open directories, making Projects entries OK when I switch back to that pane. I closed the Filesystems tab, switched to default project and back again, and still saw all [Local] in Projects tab. When I close the Projects pane, switch to default project and back again, there does not seem to be any "laziness" in displaying CVS status in explorer pane, i.e. I don't see the file statuses changing as I descend into subdirectories. As for CVS, we are using 1.11 and the repository is on a SUSE Linux server. We connect using pserver method.
I filed a similar bug. I want to note that I switch projects 2 or three times an hour. I think someone else remarked this might be related to switching projects.
I'm getting this on both the Filesystems and Project tab. Refresh and Refresh recursively seem to do nothing. Update sometimes fixes it. The tooltip always displays the correct status. I'm using 3.6rc1. I am surprised this is P3! CVS completely broke for me in netbeans because of this. I was unable to remove files because of bad status, resulting in me having to use command line to perform cvs actions!
This issue seems to be really problematic. So far already 11 people voted to have this bug fixed. That's why I am increasing its priority which is in my opinion in accordance with bug priority guidelines. Do you Martin mean its target milestone seriously ?
Most issues have target milestones set to 3.6, although only P1 defects can really go into 3.6 release currently. I expect the target milestones will be changed to promo-D after the release. This issue is hard to solve for me, because it does not happen to me. However, I understand that this is a problem for a lot of Netbeans users and we should try to investigate this. I will cooperate with Dan and will try to add some debugging information into the cache infrastructure.
Glenn Holmer found really reproducable procedure: 1. Start IDE with empty userdir. 2. Mount some empty directory as CVS filesystem with Command-line Client. (:pserver:anoncvs@cvs.netbeans.org:/cvs) 3. "CVS | Check Out" modules "diff", "i18n" and "text". 4. Statuses are updated within 1-2 seconds - all is okay now. 5. Invoke "Window | Project" menu, so that "Project Default" tab gets opened. 6. Switch back to "Filesystems" tab. 7. Right click "diff" node and choose "Tools | Add to Project" menu. 8. Do the same for "text|src|org|netbeans" directory. 9. All statuses in project tab are still okay. 10. Restart IDE. 11. Expand "diff" node - all statuses are okay. 12. However all file or directory nodes under "text" node are [Local]! Thank you CVS guru (Glenn) !
Note that steps 11 and 12 above refer to the projects pane, which should be open after steps 9 and 10.
Hey guys, I don't wanna disappoint you, but I thought we've been looking for persistance [local] status in FileSystem TAB (not in Project TAB) AFAIK if you don't expand the MAIN FS node (only possible in FS TAB) then all "links" in ProjTAB or new subFileSystems "mount as new FS" which are nested 2 or more levels deep, then all statuses are [local] till you don't expand the main FS from the TOP (possible only on original mounted FS in FS TAB) I'm afraid that it is not still what we're looking for. (BTW: I've just got [local] statuses nested deeply in main FS in FS TAB trying reproduce Jirka's reproduction case, but I'm not able repro it again)
You are both right, guys. It refers to Projects tab. To Martin: can we make some solution to this problem ? To Glenn: do you see problems with incorrect statuses in FS tab too ?
I haven't noticed this problem in the filesystems pane for some time. The problem is the projects pane. I tend to work in directories at least three levels below the main filesystems mount point, so I add them to the project pane in order not to have to expand them when I switch projects. I mostly work from the projects pane.
I've entered issue #41424 for problem with [local] statuses in ProjTAB/subFS ...That is notification problem. This current one is problem of cache synchronization, IMHO.
I would also like change bug Summary if you don't mind. From curruent one: "[36cat] CVS status not refreshed in explorer" to: "[36cat] CVS: some statuses remain [Local]. Their entries've been deleted from cache" Isn't it more descriptive, is it?;-)
OK, if you have any objections agains my proposed change of bug summary, then don't hesitate and revert it back, please. I'm changing this curruent Summary: "[36cat] CVS status not refreshed in explorer" to: "[36cat] CVS: some statuses remain [Local]. Their entries've been deleted from cache"
It's O.K., it's better descriptive now. Thanks.
I am okay with it except the two quotation marks. Changing back ...
proposed relnote: The displayed status of some files in a CVS filesystem sometimes reverts to Local. Workaround: Right-click the filesystem's node and choose CVS | Refresh Recursively.
I think your proposal sounds good. What do others think ?
:-) Very easy workaround and so much sound around it :-o Thanks Patrick for clear description to RelNotes
Sorry to chime in so late, but oftentimes when the IDE gets confused about the local status, it does not put Refresh or Refresh Recursively on the contextual menu. We need a workaround for that situation too. I think in this case, I go to the Filesystems tab and do the refresh from there, but it has been awhile so I am not sure.
I believe Chris that issue you are referring to is different problem. Please take a look at issue #41424 for details and available patch.
I hope that we'll manage to resolve this into promotion D. It can be fixed by the cache redesign (issue #32089). I'm not sure we'll be able to implement the redesign into promotion D (NB 4.0), but it's scheduled for 4.0 for now.
*** Issue 32193 has been marked as a duplicate of this issue. ***
*** Issue 42756 has been marked as a duplicate of this issue. ***
FYI: The cache redesign was not approved for 4.0 as it is considered to be too high risk. We have also many other defects to solve into 4.0, so we have also limited resources. However, Eric Hartmann created a repro-case (in the attachment). It exposes the necessity to create a disk cache for folders that do not contain CVS/ subfolders. And also issue #10301 would have to be fixed to remove [Local] status from parent folders when files in the middle of the tree are refreshed.
Created attachment 17710 [details] Eric's reproduction steps.
When the disk cache file can not be created in the working directory, we create it in the user directory. This eliminates the necessity to run refresh for the root folder when the root folder does not contain CVS folder: /cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/CommandLineVcsFileSystem.java,v <-- CommandLineVcsFileSystem.java new revision: 1.155; previous revision: 1.154
Adding dependency on issue #10301, which should solve the consistence and persistence of status information when selected files are refreshed in the middle of the tree.
After the issue #10301 is fixed, is seems that this can be marked as fixed as well. (?) At least the repro case provided by Eric now finish with correct status information. So, please reopen if you find another 100% repro case that exposes some defect behavior.
Verified.