次の環境があります。Apache 2.2.14 を使用する Windows 2008 サーバーと、WebDAV を介した SVN 1.6.6 です。複数の開発者が、異なる Windows プラットフォームから Java コードをコミットします。
ここで、コミットされたコードで Checkstyle を実行するリポジトリに pre-commit フックを実装したいと考えています。これには SVNChecker ( http://svnchecker.tigris.org/ ) を使用しますが、これは非常にうまく機能します。残念ながら、Checkstyle がエラーを報告する場合、レポートの行番号は実際の行番号の 2 倍の値になります。
SVN で何かをコミットすると、新しいファイルを含む一時ディレクトリが作成されます。次に、pre-commit フックが実行され、成功すると、新しいファイルが実際にリポジトリにコミットされます。これらの一時ファイルを Hex Editor で分析したところ、すべての改行 (\n) がキャリッジ リターンと改行 (\r\n) に置き換えられていることがわかりました。ファイルで Windows の改行 (\r\n) を使用すると、\r\r\n になり、Checkstyle といくつかのテキスト エディターでは 2 つの改行と見なされます。驚くべきことは、リポジトリからチェックアウトするときに改行が正しいため、何らかの形で改行が変換されることです。
プロパティ svn:eol-style ( http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5を参照) をネイティブに設定することで、この問題を解決できました。. すべてが正常に機能しました。残念ながら、これはリポジトリ内のすべてのファイルにこのプロパティを追加する必要があることを意味します。私の知る限り、SVN クライアントには、新しいファイルを追加するたびに自動的にこれを行う設定がありますが、残念ながら、すべての開発者にこの設定を SVN クライアントに追加するように指示することはできません。
eol-style プロパティの説明には、「デフォルトでは、Subversion はファイルで使用されている行末 (EOL) マーカーのタイプに注意を払わない」と書かれています。それにもかかわらず、改行が変換されるのは SVN のバグのように見えます。
pre-commit フックで改行を手動で変換するなどの醜い回避策を使用せずに、この動作を修正する方法を知っている人はいますか?
助けてくれてありがとう、メミンガー