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.
See issue #58543. When the IDE behaves differently from command-line CVS, and forces the user to perform manual workarounds such as editing ~/.cvsignore, this is a bug in the IDE. Especially since editing ~/.cvsignore is not satisfactory - that applies to *all* CVS checkouts, whereas you may have ignore lists which are intentionally specific to only a certain CVS repository. For example, cvs.netbeans.org currently ignores *.class - due to the existence of some old modules which fail to use a build dir - yet other servers do not, and I would not want to have *.class ignored for other checkouts, because stray *.class files might really cause problems for them.
Command line cvs does not consult CVSROOT/cvsignore either. It is the server that does that. If a user creates a new file, e.g. File.class, we cannot determine whether this file will be considered Ignored by the Update operation until we actually perform it. That is why .class files are initially shown as Local New. After an Update or Refresh operation, they are set as Ignored (in EA3, bug fixed by the patch below). We may implement hack around this by checking out CVSROOT/cvsignore first, cache and process it locally. However, not all servers lets your check it out so this is tricky. Switching to enhancement. Fixing refreshing status of files ignored on server: /cvs/javacvs/cvsmodule/src/org/netbeans/modules/versioning/system/cvss/ui/actions/update/Attic/UpdateExecutor.java,v <-- UpdateExecutor.java new revision: 1.1.2.14; previous revision: 1.1.2.13 /cvs/javacvs/cvsmodule/src/org/netbeans/modules/versioning/system/cvss/Attic/FileStatusCache.java,v <-- FileStatusCache.java new revision: 1.1.2.37; previous revision: 1.1.2.36