we have the following environment: a Windows 2008 Server with Apache 2.2.14 and SVN 1.6.6 through WebDAV. Multiple developers commit Java code from different Windows platforms.

Now we want to implement a pre-commit hook to our repository that runs Checkstyle on the committed code. We use SVNChecker (http://svnchecker.tigris.org/) for this, which works pretty well. Unfortunately, when Checkstyle reports errors, the line numbers in the reports are the double values of the actual line numbers.

When you commit something in SVN, it creates a temporary directory with the new files. Then, the pre-commit hook is run and if it succeeds, the new files are actually committed to the repository. I analysed these temporary files in a Hex Editor and found out that all newlines ( ) were replaced by a carriage return and a newline ( ). As we use Windows line-breaks ( ) in our files, this resulted in , which is considered as two newlines by Checkstyle and several text editors. The strage thing is that the line-breaks are correct when checking out from our repository, so they are somehow converted back somewhere.

I could solve this problem by setting the property svn:eol-style (see http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5) to native. Everything worked as it should then. Unfortunately, for us this would mean that we would have to add this property to every file in our repository. As far as I know, there is a setting in the SVN client that does this automatically whenever you add a new file, but unfortunately we cannot tell all our developers to add this setting to their SVN client.

The description of the eol-style property says "by default, Subversion doesn t pay any attention to the type of end-of-line (EOL) markers used in your files". To me, it looks like a bug in SVN that the newlines are converted nevertheless.

Does anyone have an idea how to fix this behaviour without using ugly workarounds such as manually converting the newlines back in the pre-commit hook?

Thanks for your help, memminger