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.
Product Version = NetBeans IDE 6.9 RC2 (Build 201005312001) Operating System = Windows 7 version 6.1 running on x86 Java; VM; Vendor = 1.6.0_20 Runtime = Java HotSpot(TM) Client VM 16.3-b01 I will submit comparative screen shots with RC1. The issue is that RC2 shows 2 files as New and 1 file as Modified, but they are not not either. The screen shot from RC1 will confirm this.
Well, after I submitted this ticket, RC1 started showing these as well. Still, the files are NOT New or Modified. I forgot to put in my description, that the way I knew this was partially because Netbeans will not allow me to Commit these files, which I will screen shot, plus I will screen shot the CVS repository to show the files as not being new. Finally, I have only [{tag}] in my status label option, and these files are showing additional information ([New] & [Modified]), which they should not be showing (no other files are doing this, so I assume it is not a separate bug to be filed.)
Created attachment 99845 [details] Netbeans with incorrect project entries
Created attachment 99846 [details] CVS Entries file showing files are not new
Created attachment 99847 [details] CVS repository showing files are not new
Could you please check one thing? If you right-click on any of the files, does CVS submenu appear in the context menu? Or is Subversion/Mercurial menu shown instead? Could you also look into the folder (library/classes) and look for .svn or .hg folder inside? Because it looks like those files are tracked by other version control system than CVS.
I did not get an email that this had been updated.
Ok, you were correct about the .svn. However, why does this cause Netbeans a problem? It doesn't cause SmartCVS a problem and the CVS files are there, as they should be.
> why does this cause Netbeans a problem? I don't see any problem here. You simply have a nested working copy which takes precedence from the parent (CVS) working copy so all the files inside the folder are considered to be under Subversion control instead. > It doesn't cause SmartCVS a problem and the CVS files are there, as they should be Sure, but SmartCVS does not need to track other kinds of working copies (subversion, mercurial, etc.), does it? Because we support other VCSs we need to handle these nested repositories. Please if you don't need the .svn folder, delete it and the files should be correctly recognized as under CVS control. I guess you can vote for #146824 which would probably introduce a possibility to suppress subversion control of the folder and thus solve your problem.