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: | After unloading and reloading JavaCVS module, JavaCVS filesystem has local filesystem icon | ||
---|---|---|---|
Product: | versioncontrol | Reporter: | _ tboudreau <tboudreau> |
Component: | CVS | Assignee: | Martin Entlicher <mentlicher> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | jtulach, mentlicher, mihmax |
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Screenshot of the problem
Snapshot of broken JavaCVS commit log. |
Description
_ tboudreau
2002-04-08 21:31:23 UTC
Created attachment 5325 [details]
Screenshot of the problem
can this be a problem of early versions of treefs, yarda? Finally someone else than just me realized this. It happens to me from time to time. I have "all@netbeans.org" CVS repository mounted as one filesystem and a lot of views over it (ten at least). Switching two such projects often results in the CVS filesystem to become completely empty. Btw. my CVS filesystem is global (in Tools/Options UserLayer, not project one), so it should not change. In my opinion this is not bug in TreeFS, because the content of CVS filesystem is empty and it should not be influence by view over it. can you reproduce it without the treefs? if not I assume it to be the fault of treefs, rather then cvs filesystem. Milos moving to treefs for deeper evaluation. Milos, it is not true, I have explained to you that this is bug in javacvs. If you want, I stop by and I can reproduce it for you. Created attachment 6603 [details]
Snapshot of broken JavaCVS
As you can see on the previous snapshot, the CVS filesystem shows no files under work directory, but LocalFS gives evidence that they are there. Looks like a serious problem is not it? what's under the local filesystem in the picture? you have any treefs mounted? what are the exact steps to reproduce? it works for me and I didn't get similar problems for quite some time (6-9+ months) I've switched several times the projects now, each with 10+ treefs over the cvs filesystem at different levels of depth and cannot reproduce it. BTW yarda you didn't explain anything. You just claim that it happens for you after switching projects. and that it's not fault of treefs. your claim here is based on the fact that the filesystem should expand. You also mentioned some non-standard setting of the filesystem on a non-project layer.. May I assume all filesystems being on that level or just the cvs one and the treefs filesystems over it are project based? That leads me to an assumption that the problem might lie in the automount support, in code that switches projects or the serialization of treefs. These explanations are as valid as is yours above IMO. Milos, it is right that the environment around can cause all the problems that the javacvs has, but these are really problems of javacvs. I checked: 1. after start of the ide NbJavaCvsFileSystem@4bce3 is mounted 2. after switch to different project the same filesystem is mounted 3. its getRoot ().getChildren ().length == 0 So there is something wrong in the javacvs filesystem. I can reproduce it everytime, stop by if you cannot. Created attachment 6634 [details]
commit log.
fixed in trunk. diff (commit log attachement) attached. [Martin, please review] Description of the fix: on multifilesystems it's not guaranteed that the uderlying filesystem's addNotify and removeNotify methods will be called subsequently and in the right order. With a simple test I figured that the addNotify is called multiple times (for each treefs on it once) 1. in removeNotify it was attempted to clean up cache too agressively without a counterpart in addNotify, the lost connection resulted in empty filesystem. (only sometimes, depending on the garbage collection cycle) fixed by keeping reference to listener in filesystem so that the it's weakListener is not gc-ed. 2. made creation/disposal of versioning filesystem synchronized. Only the blocks that are posted to the request processor. The diff seems O.K. and safe to me. merged into the release34 branch I have seen the issue again in post 3.4 builds that I am using. Everytime I switch project, the javacvs is "emptied", very likely due to unequal number of removeNotify & addNotify calls. O.K., I'll look on it... I've tested this at least 10 times with >20 treefs mounted from the original javacvs filesystem. I've restarted IDE several times and changed projects several times. Every time I was able to expand the CVS filesystem and got the correct children. Any hints how to reproduce this appreciated. Does the "no children problem" appear only on the original CVS filesystem or on the treefs also? I can give you access to my machine, or show it to you. I am able to reproduce it every time. No children problem is on JavaCVS, as a result each FS that delegates to it will hava no children too. Ok? Thanks for providing me the access to your machine! After I've seen how it works on your machine and looked into the code I was suprised, that it works on Solaris. The cache system was not initialized fully after addNotify(). I was able to identify the problem and the changes I've made seems to fix the problem on your machine completely. Fixed in the main trunk. Diffs: http://javacvs.netbeans.org/source/browse/javacvs/src/org/netbeans/modules/javacvs/caching/CvsFsCache.java.diff?r1=1.29&r2=1.30 http://javacvs.netbeans.org/source/browse/javacvs/src/org/netbeans/modules/javacvs/JavaCvsFileSystem.java.diff?r1=1.85&r2=1.86 Switch of project succeeded now (used to fail before). *** Issue 26622 has been marked as a duplicate of this issue. *** *** Issue 24345 has been marked as a duplicate of this issue. *** So this seems to be a bug in version 3.4 => changing version from 4.0 to 3.4 for sustaining reasons. Adding 3.4.1_CANDIDATE, this should go into 3.4.1 IMHO. 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. Merged into release341 branch. /cvs/javacvs/src/org/netbeans/modules/javacvs/JavaCvsFileSystem.java,v <-- JavaCvsFileSystem.java new revision: 1.82.4.3.4.1; previous revision: 1.82.4.3 /cvs/javacvs/src/org/netbeans/modules/javacvs/caching/CvsFsCache.java,v <-- CvsFsCache.java new revision: 1.28.6.1.4.1; previous revision: 1.28.6.1 Broken again in main trunk. What about writing a test to prevent regressions? Good idea, what do you think Daniel ? I love these kinds of bugs, that somehow break by themselves without any apparent reason :) I'll look at it... Please don't change the target milestone, otherwise how IZ can know, what has been fixed in 3.4.1? http://www.netbeans.org/issues/buglist.cgi? target_milestone=3.4.1 If you feel that this functionality is broken or you need a TASK to create a test, rather file a separate issue(s). Well, yes. Maxym is right. This is fixed in 3.4.1 and thus should not be reopened. See issue #30763 for the problems in 3.5 dev builds. Marking as verified - it was already verified. Resolved for 3.4.x or earlier, no new info since then -> closing. |