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.
Description: Nevada Build 030323, Win XP, JDK 1.4.1_02 -Have an existing application MyApp1 [Up-to-date] in a package Alex in a mounted CVS filesystem; -Selected an application MyApp1 [Up-to-date] and chosen popup menu > CVS > Check Out. The command was finished but I've noticed that a sub-package Alex was created with the same MyApp1 [Needs Update] in it. ----------------------------- I am going to attempt a different description of this bug. The first thing to note is that this bug is reproducable purely with Java objects and is very likely to exist in a pure NetBeans distribution. Assume the following file/directory structure. pkg/TestFile.java 1: Using an already mounted CVS file system select cvs source controlled object (pkg/TestFile.java) and invoke checkout from the context menu. 2: The act of checking out the file will create a new directory ant the resulting file set will be: pkg/TestFile.java pkg/pkg/TestFile.java Evaluation: We need to see the underlying cvs commands that were run from runtime tab->VCS commands. Possibly the cvs checkout is running in the wrong directory. xxx@xxxx 2003-03-25 I am able to reproduce this on Alex's machine but not on my own machine. Before bug bridging this over I would like to see the way this file system was originally mounted. xxx@xxxx 2003-03-26 Ok, more information. This looks like a problem with using the "external" cvs client, not the internal one. I will check with Alex when I see him next. In my testing if I mount this using the built in client I don't have a problem. With the external client this seems to happen. xxx@xxxx 2003-03-26 A comment.
Evaluation: We need to see the underlying cvs commands that were run from runtime tab->VCS commands. Possibly the cvs checkout is running in the wrong directory. andrew.sherman@sun.com 2003-03-25 I am able to reproduce this on Alex's machine but not on my own machine. Before bug bridging this over I would like to see the way this file system was originally mounted. michael.ottati@sun.com 2003-03-26 Ok, more information. This looks like a problem with using the "external" cvs client, not the internal one. I will check with Alex when I see him next. In my testing if I mount this using the built in client I don't have a problem. With the external client this seems to happen. michael.ottati@sun.com 2003-03-26
The checkout command is correct. The execution string and the output of the command can be seen in the Runtime tab under "VCS Commands" node. The problem is in the display of the result. The checked out folders/files are incorrectly displayed in a wrong folder.
Hm, this is really ugly. I think this must be definetely fixed into Sun ONE Studio 5.0. I am ready to help with verification of fix. Can you Martin provide me a patch ?
I agree, it's ugly. As soon as I have the patch I'll attach it here. The fix is not straightforward, this probably didn't work correctly even in 3.4, although the current behavior is much worse. To fix this I will have introduce a new property of VCS commands, that will appear on "Refresh Info" tab of the Command Editor. The property will be named like "Relative File Path" and will contain the relative path with respect to the ROOTDIR (the Working Directory) of the refreshed files. This is necessary because update and checkout return processed files relative to different directories. This property might be necessary anyway for other 3rd party profiles, it's a deficiency in the current architecture that this property is not there.
The fix is done in the main trunk at several places: In vcscore module, the base relative folder of refreshed file is computed and the name of the appropriate property is introduced: /cvs/vcscore/src/org/netbeans/modules/vcscore/cmdline/ExecuteCommand.java,v <-- ExecuteCommand.java new revision: 1.61; previous revision: 1.60 /cvs/vcscore/src/org/netbeans/modules/vcscore/cmdline/UserCommand.java,v <-- UserCommand.java new revision: 1.15; previous revision: 1.14 In vcsgeneric module, the new property is put into the command's property sheet: /cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/commands/Bundle.properties,v <-- Bundle.properties new revision: 1.36; previous revision: 1.35 /cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/commands/CommandNode.java,v <-- CommandNode.java new revision: 1.38; previous revision: 1.37 And finally the property is added into cvs profiles: /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/cvsUnix.xml,v <-- cvsUnix.xml new revision: 1.31; previous revision: 1.30 /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/cvsWin.xml,v <-- cvsWin.xml new revision: 1.33; previous revision: 1.32 /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/cvsWin98.xml,v <-- cvsWin98.xml new revision: 1.32; previous revision: 1.31 Also upgrading to P1 -- this is a showstopper for NB 3.5/S1S 5.0
Created attachment 9650 [details] The context diff with respect to release35 branch.
Created attachment 9651 [details] The binary patch for vcscore module. Put into <NB-install>/modules/autoload/patches/org-netbeans-modules-vcscore/ folder.
Created attachment 9652 [details] The binary patch for vcsgeneric module. Put into <NB-install>/modules/patches/org-netbeans-modules-vcs-advanced/ folder.
Created attachment 9654 [details] Patched cvs profiles. Extract the jar in <NB-user-dir>/system/vcs/ folder.
Hm, looks good so far. I had to remount the filesystem to fix the problem however file was checked out correctly and no ghost nodes appeared. Verified in Sun ONE Studio #030401 with all three above attached patches.
Reviewed. Looks ok for me.
approved for 3.5
Thanks for the review and approval. The fix is merged into release35 branch: Checking in vcscore/src/org/netbeans/modules/vcscore/cmdline/ExecuteCommand.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/cmdline/ExecuteCommand.java,v <-- ExecuteCommand.java new revision: 1.60.2.1; previous revision: 1.60 done Checking in vcscore/src/org/netbeans/modules/vcscore/cmdline/UserCommand.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/cmdline/UserCommand.java,v <-- UserCommand.java new revision: 1.14.2.1; previous revision: 1.14 done Processing log script arguments... More commits to come... Checking in vcsgeneric/src/org/netbeans/modules/vcs/advanced/commands/Bundle.properties; /cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/commands/Bundle.properties,v <-- Bundle.properties new revision: 1.35.2.1; previous revision: 1.35 done Checking in vcsgeneric/src/org/netbeans/modules/vcs/advanced/commands/CommandNode.java; /cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/commands/CommandNode.java,v <-- CommandNode.java new revision: 1.37.2.1; previous revision: 1.37 done Processing log script arguments... More commits to come... Checking in vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/cvsUnix.xml; /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/cvsUnix.xml,v <-- cvsUnix.xml new revision: 1.28.4.3; previous revision: 1.28.4.2 done Checking in vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/cvsWin.xml; /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/cvsWin.xml,v <-- cvsWin.xml new revision: 1.30.4.3; previous revision: 1.30.4.2 done Checking in vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/cvsWin98.xml; /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/cvsWin98.xml,v <-- cvsWin98.xml new revision: 1.29.4.3; previous revision: 1.29.4.2 done
Vix was verified in Sun ONE Studio 5. Used the same scenario as in description and was unable to reproduce.