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.

Bug 174389 - CVS checkin of new (non Java) files adds 0xd to end of lines
Summary: CVS checkin of new (non Java) files adds 0xd to end of lines
Status: NEW
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: CVS (show other bugs)
Version: 6.x
Hardware: Macintosh Mac OS X
: P3 blocker (vote)
Assignee: issues@versioncontrol
Depends on:
Reported: 2009-10-12 19:03 UTC by vincesheard
Modified: 2010-07-30 09:52 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description vincesheard 2009-10-12 19:03:08 UTC
When you add new files to a cvs repository that are not Java files from a MAC OS system it adds a 0xd to the end of 
each line. This creates issues with the ant scripts when the file is then checked out on a windows OS machine.
Comment 1 vincesheard 2009-10-12 19:08:32 UTC
We found that the cvs plug-in for NetBeans (when running in a Mac) adds an extra 0x0d at the end of the line of xml 
files and other non-java files in the process of creating them (I am not sure about commiting after a file is already 
created). You can see the extra 0x0d in the server files (the *,v files). When you get (cvs up) a file like this out in 
a Linux box, the extra 0x0d is removed. But in windows the extra 0x0d is not removed (since there is supposed to be one 
around the end of line) and you have an end of line that looks like 0x0d, 0x0a, 0x0d. Ant does not like that in the so the build fails. Also, the extra 0x0d causes problems such as when NetBeans reads the file that contains 
the friendly name of the project (Module Name). It does not like the extra 0xd and puts instead the full path of the 
module name. 
Comment 2 Ondrej Vrabec 2009-10-13 10:15:46 UTC
I am not aware of any '\r' adding in our cvs module. The only relevant thing that comes to my mind is the line-endings
conversion we're doing when committing a file. When the system line separator is anything other than '\n', we replace
any line-endings in the file with '\n'. However if you're using Mac OS X, your system line-separator should be set to
'\n', so no conversion should be needed (and no conversion should be applied).

Could it be that the file had already contained '\r' before you tried to add it to the repository? E.g. it was
originally created on windows and than moved to Mac OS or anything like it?
Did you create that file in netbeans?
What is System.getProperty('line.separator') set to?
Comment 3 vincesheard 2009-10-13 20:28:12 UTC
Your analysys was correct.
The file was originally created in NetBeans on Windows, and then moved it to the Mac.  It then got checked into CVS 
from the Mac.  So, it is quite likely that it had \r\n after each line, and then the CVS module replaced the \r with a 
\n, so each line now had a \n\n on it.
Maybe the substitute should not be a straight exchange, but a little more smart to check what already exists.
I do not see this as a high priority now though. More of a low level fix for a corner case.