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.
When importing a new project (with jar files) to a CVS server running on RHEL-AS3 over ssh using public key authentication the jar files seem to be getting corrupted. Once the project is checked out from the cvs, the ide is unable to load the jar files. The netbeans build info: ----------------------- NetBeans dev build ------------------ Number: 200512182030 Date: ${buildday} Branding: Branch: trunk Tag: Development environment info: ----------------------------- Client OS: Windows XP_sp2 JDK:jdk150_06 CVS Server OS: RHEL-AS3 CVS Version: 1.11.2 CVS Protocol:extssh Authentication Method:public key authentication
This issue was reported by NetCAT 5.0 program participant.
My guess is that the jar was added as textual. Is it true?
> The "cvswrappers" solution recommended by Peter seem to help work around > this... It marks files as binary.
wrappers solution: The best practice for importing sources successfully is to set up *cvswrappers* file in *CVSROOT* in repository. If you add "*.jar -k 'b'" to this file, *.jar files will be imported correctly.
-------------------------------------------------------------------------------- Peter Pis wrote: *cvswrappers* takes affect before files are imported into the repository. So if your file was added textually, the best solution would be to delete the file from repository and add it as binary once more.
*** Issue 30112 has been marked as a duplicate of this issue. ***
While I doubt that this cause of this problem is specific to any particular CVS authentication method or client platform, I can confirm that it affects CVS pserver using NetBeans on Windows XP. Indeed, using cvswrappers might be the best solution in the interim. Some users may not have sufficient access to the repository to modify it, though. Even though I am a very experienced CVS user, I doubt I have had to use a cvswrappers file in three years, since most graphical CVS clients allow you to map common file extensions as being text or binary, and come with a set of sensible default values. Here is my suggestion for your cvswrappers file's contents until the problem is fixed. Maybe this could also be used as a starting point for which files are treated as binary by default in NetBeans: # Image formats *.gif -k 'b' *.png -k 'b' *.jpg -k 'b' *.bmp -k 'b' *.tiff -k 'b' *.tif -k 'b' *.tga -k 'b' *.ico -k 'b' *.pdf -k 'b' *.ps -k 'b' *.eps -k 'b' *.xcf -k 'b' *.wmf -k 'b' # compressed/executable formats *.jar -k 'b' *.zip -k 'b' *.tar -k 'b' *.tgz -k 'b' *.gz -k 'b' *.tar.gz -k 'b' *.exe -k 'b' *.class -k 'b' *.rpm -k 'b' *.msi -k 'b' *.bz2 -k 'b' *.z -k 'b' *.dll -k 'b' *.so -k 'b' *.hqx -k 'b' *.lib -k 'b' *.bin -k 'b' # MS Office formats *.doc -k 'b' *.xls -k 'b' *.ppt -k 'b' *.mdb -k 'b'
*** Issue 72832 has been marked as a duplicate of this issue. ***
I suggest that we fix this by putting an additional field in the Import wizard where the user would provide masks for binary files. Or provide a button there which will launch editor for 'local wrappers'. We need some kind of UI there because we cannot possibly guess all types of files that are binary. Anyway, I consider this to be an enhancement.
Clearly msandor seems correct that "we cannot possibly guess all types of files that are binary" and further this is would probably be an inherently faulty strategy. Given that data loss can occur with failing to mark a file as binary, perhaps inverting the approach, to be more defensive, would be significantly more appropriate. Specifically, it seems fairly obvious that the default for any unknown files should be binary, to avoid any possible data loss. A very conservative (and user-configurable) whitelist of extensions known to be text would be more than sufficient to avoid almost any unexpected data loss. Here's a potential list of default text extensions: css htm html java js jsp txt xml Hopefully this will be both easier to implement and more reasonable as a strategy to avoid data loss.
*** Issue 99107 has been marked as a duplicate of this issue. ***
*** Issue 125208 has been marked as a duplicate of this issue. ***
*** Issue 127912 has been marked as a duplicate of this issue. ***
*** Issue 173812 has been marked as a duplicate of this issue. ***