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.