Как избежать преобразования строки (приводящего к неправильным номерам строк) в ловушке предварительной фиксации Subversion?

Question

у нас есть следующая среда: Windows 2008 Server с Apache 2.2.14 и SVN 1.6.6 через WebDAV. Несколько разработчиков передают Java-код с разных платформ Windows.

Теперь мы хотим реализовать хук предварительной фиксации в нашем репозитории, который запускает Checkstyle для зафиксированного кода. Для этого мы используем SVNChecker (http://svnchecker.tigris.org/), который работает довольно хорошо. К сожалению, когда Checkstyle сообщает об ошибках, номера строк в отчетах являются двойными значениями фактических номеров строк.

Когда вы фиксируете что-то в SVN, он создает временный каталог с новыми файлами. Затем запускается ловушка предварительной фиксации, и в случае успеха новые файлы фактически фиксируются в репозитории. Я проанализировал эти временные файлы в шестнадцатеричном редакторе и обнаружил, что все новые строки (\ n) были заменены на возврат каретки и новую строку (\ r \ n). Поскольку в наших файлах используются разрывы строк Windows (\ r \ n), это привело к появлению \ r \ r \ n, который рассматривается Checkstyle как две новые строки и несколько текстовых редакторов. Самое странное, что разрывы строк корректны при проверке из нашего хранилища, поэтому они каким-то образом конвертируются обратно куда-то.

Я мог бы решить эту проблему, установив свойство svn: eol-style (см. http://svnbook.red -bean.com / ru / 1.1 / ch07s02.html # svn-ch-7-sect-2.3.5 ) до родного. Все работало как надо тогда. К сожалению, для нас это будет означать, что нам нужно будет добавить это свойство в каждый файл нашего репозитория. Насколько я знаю, в SVN-клиенте есть настройка, которая делает это автоматически всякий раз, когда вы добавляете новый файл, но, к сожалению, мы не можем сказать всем нашим разработчикам добавить этот параметр в их SVN-клиент.

Описание свойства eol-style гласит: «по умолчанию Subversion не обращает никакого внимания на тип маркеров конца строки (EOL), используемых в ваших файлах». Для меня это похоже на ошибку в SVN, что переводы строк все же преобразуются.

У кого-нибудь есть идеи, как исправить это поведение, не используя уродливые обходные пути, такие как ручное преобразование новых строк обратно в ловушку перед фиксацией?

Спасибо за вашу помощь, Memminger

Answer 1

Мое предположение, что SVN создал временный каталог для ловушек перед фиксацией, было неверным. Вместо этого ловушка предварительной фиксации может получить доступ к исходным файлам, используя svnlook и номер транзакции. SVNChecker - это тот, кто сохраняет эти файлы во временном каталоге.

То, что вызывает неправильные разделители строк, - это функция Python, которая автоматически конвертирует разрывы строк, так что все приложения Python могут использовать разделители строк Unix внутри. Однако только некоторые функции по умолчанию преобразуют разрывы строк из внешних источников во внутренние переводы Python. SVNChecker не позаботится об этом, о чем уже сообщалось как об ошибке на http://svnchecker.tigris.org/issues/show_bug.cgi?id=33.