set svn:eol-style for .java files

[GoogleCodeExporter]

We should set svn:eol-style=native for all .java files. I keep seeing checkins 
where every line in the file has been "changed" because the last person to edit 
it was on a different platform.

Original issue reported on code.google.com by steven.b...@gmail.com on 28 Dec 2010 at 4:37

[GoogleCodeExporter]

[from Richard]
Btw. I configure the EOL-type in the Eclipse workspace settings to "Windows" 
even though I am working on OS X or Linux. The reason for this is, that I make 
a concession to the poor Windows users often suffer from editors that are not 
aware that Windows is not the only system on Earth and would render everything 
into a single line.

I suggest configuring EOL-type as well as encoding (UTF-8) in the Eclipse 
workspace. In particular encoding could not be configured anywhere else anyway.

Original comment by pvogren@gmail.com on 28 Dec 2010 at 5:57

[GoogleCodeExporter]

The situation you (Richard) describe is pretty much exactly what 
svn:eol-style=native is designed for:

http://svnbook.red-bean.com/en/1.1/ch07s02.html
(search for the heading "svn:eol-style")

It will give Windows users \r\n newlines so that all their editors work. It 
will also give OS X and Linux users \n newlines so that, e.g. Emacs won't show 
^M characters everywhere.

It's a better solution than just setting the Eclipse workspace because it will 
work if anyone happens to be using Netbeans, IntelliJ, Emacs or some other 
editor.

Original comment by steven.b...@gmail.com on 28 Dec 2010 at 6:31

[GoogleCodeExporter]

I couldn't figure out how to recursively set the property on all .java files.  
The following documentation that I got from running "svn propset help" says:  

The svn:keywords, svn:executable, svn:eol-style, svn:mime-type and
svn:needs-lock properties cannot be set on a directory.  A non-recursive
attempt will fail, and a recursive attempt will set the property
only on the file children of the directory.

So, this makes me think that it doesn't work the way you would hope - so I did 
it manually directory-by-directory using the following command:

svn propset svn:eol-style native *.java

I also added the following line to my subversion config file (located at 
C:\Users\Philip\AppData\Roaming\Subversion\config on my machine):

*.java = svn:eol-style=native

I'm not sure where to add these two tidbits of information so that they aren't 
forgotten.  Probably the DeveloperSetup page.  

Original comment by pvogren@gmail.com on 3 Jan 2011 at 11:13

• Changed state: Fixed

[GoogleCodeExporter]

I added some comments about subversion properties to the DeveloperSetup page.

Original comment by pvogren@gmail.com on 3 Jan 2011 at 11:31

[GoogleCodeExporter]

That all sounds right. Thanks for fixing this, and I've updated my subversion 
config as well.

Original comment by steven.b...@gmail.com on 4 Jan 2011 at 3:22

[GoogleCodeExporter]

I don't like changing my global subversion config. Did your research on that 
topic yield any hints as to whether such settings can be made local to a 
specific project?

Original comment by richard.eckart on 5 Jan 2011 at 8:23

[GoogleCodeExporter]

I didn't see a way to do that.

But I'm also not worried about it - I *never* want Java files with anything 
other than svn:eol-style=native. Anything other than that is asking for 
cross-platform trouble.

Original comment by steven.b...@gmail.com on 5 Jan 2011 at 3:15

[GoogleCodeExporter]

I wonder if there is something in Maven that could help with this?

Original comment by pvogren@gmail.com on 5 Jan 2011 at 5:22

[GoogleCodeExporter]

I am reconsidering that setting this globally may not be harmful. What about 
the Javadoc HTMl or XML files? Should these also have the eol style set?

Original comment by richard.eckart on 6 Jan 2011 at 8:03

[GoogleCodeExporter]

If you check the DeveloperSetup, Philip suggested:

*.html = svn:mime-type=text/html

though I don't know if he actually set those for the javadoc. I imagine we 
should also set:

*.html = svn:mime-type=text/xml

Perhaps we should just steal an extensive list from another project, e.g.

http://www.bioperl.org/wiki/Svn_auto-props

I note that this one (and others I've seen) also set svn:eol-style native for 
HTML and XML as well, which probably makes sense since they're text files.

Original comment by steven.b...@gmail.com on 7 Jan 2011 at 3:26

[GoogleCodeExporter]

I think you can only assign a single mime type to a file type. Since not all 
HTML files are valid XML "svn:mime-type=text/html" should be the better option. 
Looking at the bioperl list of autoprops, I assume that setting the mime type 
is independent from setting the eol style.

At least for XML files it's probably a bad idea to set a native eol style, 
because they may contain CDATA sections which should probably be treated as 
binary data. I also suppose that an eol style may break signatures embedded in 
XML files (hash sums change) which I assume not to be aware of 
platform-specific line endings. While I did not put these assumptions to the 
test, I revise my question to the advice of being cautious of globally enabling 
eol style for XML files or files that may be XML (e.g. HTML). It may be 
reasonable for a particular project or a particular set of files, but I believe 
it can be harmful for XML-like files in general.

Original comment by richard.eckart on 7 Jan 2011 at 8:58

[GoogleCodeExporter]

Sorry, I meant to say I imagine we should also set:

*.xml = svn:mime-type=text/xml

Original comment by steven.b...@gmail.com on 7 Jan 2011 at 4:30

[GoogleCodeExporter]

Fair enough about the eol style for HTML/XML.

Original comment by steven.b...@gmail.com on 7 Jan 2011 at 4:31

[GoogleCodeExporter]

Original comment by richard.eckart on 7 Apr 2011 at 12:12

• Added labels: Milestone-1.2.0

[GoogleCodeExporter]

Original comment by richard.eckart on 8 May 2011 at 10:43