Just in case anyone else following this that are still fuzzy on the details due to the acronyms.
CRLF is the windows version of a new line. "\r\n" carriage return,line feed. or in c# Environment.NewLine; eol = end of line. eof = end of file. FOSS projects that will possibly run on multiple platforms generally have to be more aware of this than others. http://en.wikipedia.org/wiki/Newline I sometimes forget about this kind of thing myself. but scm generally has ways to checkout in one format and commit back in the other. I know that git has options for this. You might get notices from visual studio about switching the line breaks to crlf if the file is not in that format. text-editor behavior varies. On Sun, Nov 13, 2011 at 2:25 AM, Stefan Bodewig (Commented) (JIRA) < j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/LUCENENET-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149241#comment-13149241] > > Stefan Bodewig commented on LUCENENET-453: > ------------------------------------------ > > Basically I did something like > > find . -name \*.cs -print0 | xargs -0 -e svn ps svn:eol-style native > > i.e. I set the eol-style to native for all C# sources and then used "svn > status" to see which ones didn't have that already. Repeat for the other > file types I expected to have bad line-ends. Another approach would be to > run Ant's fixcrlf task over the tree and see what gets changed. I'm sure > there are other ways to do this. > > svn will complain if you try to set the svn:eol-style property on a file > with a binary MIME type. When I started to write the comment I expected to > find more files than the one, that's why it reads a bit weird. Yes, AFAIR > this was the only binary source file. > > svn tracks line-feed information in the svn:eol-style property. By > default it doesn't do any transformations at all. If you set it to native > then all line-feeds will be transformed when checking out files (I think > svn uses \n internally) to your platform's default and back on commit. > Apart from native there are explicit values for "always \n" and so on. > You use that for files that are only meaningful on specific platforms > (shell scripts and batch files, mostly). build.cmd is Windows only so it > makes sense to set the property to "CRLF". > > See > http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style > > > Many files need proper svn properties to set the linefeeds > > ---------------------------------------------------------- > > > > Key: LUCENENET-453 > > URL: https://issues.apache.org/jira/browse/LUCENENET-453 > > Project: Lucene.Net > > Issue Type: Bug > > Reporter: Stefan Bodewig > > Priority: Minor > > Attachments: LUCENENET-453.inconsistent-eol.patch, > LUCENENET-453.list-of-files-with-missing-svn_eol-style.txt > > > > > > Many files are lacking the svn:eol-style proper which should be set to > native, I'll attach a list later. > > Some files have inconsistent linefeeds, I'll attach a patch. > > Some files even have bad mine-types. You need to run > > svn pd svn:mime-type > > on > > test/contrib/Core/Analysis/Ext/Analysis.Ext.Test.cs > > build.cmd should likely get an svn:eol-style of crlf > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators: > https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira > > >
