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.
We have the following setup in our Web project: project - src ( contains the java sources ) - web ( contains the web project including the jsps ) --- all jsp files and directories containing JSPs --- WEB-INF ------- classes ------- lib ------- web.xml, etc The entire project has been checked into to the CVS with the server hosted on a Mandrake Linux 9.0 server running cvs server. To mount the folders to work with, we first mount the src directory as a javacvs file system and then mount the web folder. On mounting the web folder, we get a dialog saying that it has been identified as a web project and an alternate view is available in the project tab. We currently do not use the project tab, so we ignore this message. In most cases ( not in all ), when we commit changes or run updates on the files in the two mounted filesystems, the cvs output window that opens shows the addition of two tabs, we could not figure out for long what it was. One used to fail all the time while the other commited/updates. These are the operations we use most frequently. Sicne this happened very frequently, we started assuming that this is a feature of netbeans to open two tabs. But lately we have been losing changes whenever we update one particular file or directory. This behaviour has also been seen when we commit files. Most of the times, even though we commit files on the src filesystem, Netbeans takes the liberty of commiting files in the web filesystem, WEB-INF folder. This has caused us considerable damage at times when we were working hard on deadline dates.
I'll try to reproduce it, I've found one possibly related issue #27050
I was able to reproduce it. It seems, that it's necessary to have the second filesystem set as a compilation target. Is this true in your case as well?
Don't know what you mean by second file system. When the web file system is mounted, another file system web/WEB-INF/classes is automatically mounted. This "classes" file system needs to be set as the target file system for the Java compilation.
Hm, strange. It seems like it is not 100% reproducable. I tried to set it up like you did it (with Martin looking over my shoulder :-) and nothing. Also it seems that many conditions must be satisfied in order to invoke this bug. We need more investigation ...
Cool, hm :-\ I was able to finally reproduce it too. I had problems with my package structure. Class that is going to be commited must be properly compiled to another target. If the bug is reproduced, command opens dialog with two tabs and there is the same command executed on the CVS filesystem recognized as web project in Runtime tab. Result is unintended command on whole working directory !
I was finally able to find out what's happening there. There're two cases which makes the issue harder to reproduce: 1) The compile target filesystem is initially collapsed in the Explorer and you've compiled the classes under src folder. In this case the compiled classes are considered as "unimportant" (that is a result of the compilation, that can be re-generated) and therefore CVS commands are not executed on them. Due to a bug however the target filesystem is detected and the actions are executed on the whole filesystem. This case is easy to fix. 2) The compile target filesystem is expanded in the Explorer and you've compiled the classes under src folder. In this case the compiled classes are considered as "important" (because Class data object detects only the class files without corresponding .java files). This is the case when the CVS actions are executed on both .java and .class files and fail on .class files. Generally it's supposed that when the .class files are on CVS filesystem, you want to invoke CVS actions on them. So one solution would be to mount the classes as a Local Filesystem. Another solution would be to detect this state and do not invoke CVS actions on files, that belongs to more than one DataObject. However this detection can have a slight performance impact. IMHO 1) is definitely a showstopper and should be fixed in NB 3.5. 2) seems to me as a very annoying P2, which cause a bad user experience. It would be nice to have this fixed in NB 3.5 as well. Moreover case 2) is not deterministic, thus the user observe different behavior from time to time.
One more note: Case 1) is specific for javacvs and should be fixed just there, case 2) is common for both javacvs and command-line VCS integration and if it should be addressed, than ONLY in 3.5 codebase (in 4.0 the Java data object behavior is different).
I've split this issue into two, I've submitted issue #33323 for the second problem. I'm going to attach patches and diff for the fix of the problem described in case 1) so that it can be fixed in NB 3.5.
Created attachment 10196 [details] The binary patch, that fix the first problem. To apply, put into <NB-install>/modules/patches/org-netbeans-modules-cvsclient/ folder.
Created attachment 10197 [details] The contextual diff of the fix.
The problem is also fixed in the main trunk. Checking in JavaCvsActionSupporter.java; /cvs/javacvs/src/org/netbeans/modules/cvsclient/actions/JavaCvsActionSupporter.java,v <-- JavaCvsActionSupporter.java new revision: 1.9; previous revision: 1.8 done
Okay, I tested the core part of this issue and it seems all right. If the class files are not loaded it behaves exactly as it should. I also walked around the affected area and typical command execution works fine so far. Tested with RC build #030428_1 of Sun ONE Studio 5.0 with Patch33310.jar on Windows 2000 with JDK 1.4.1 build #02.
Code reviewed without objections.
approved for 3.5
Thanks for verification, review and approval. The problem is fixed in release35 branch: Checking in JavaCvsActionSupporter.java; /cvs/javacvs/src/org/netbeans/modules/cvsclient/actions/JavaCvsActionSupporter.java,v <-- JavaCvsActionSupporter.java new revision: 1.7.30.2; previous revision: 1.7.30.1 done
Perfect. Verifying in FCS build of Sun ONE Studio 5.0 #030528.