EOL в репозитории SVN, установив его в CRLF

Question

Я перемещаю CVS-репозиторий в Subversion с помощью инструмента polorion. Когда я импортирую дамп, созданный с помощью загрузки svnadmin, автоматически.java и.txt файлы устанавливаются в CRLF EOL. Но XML и HTML остаются как LF.

Требуется установить все эти файлы с EOL в качестве CRLF. Я настроил C:\Users\\AppData\Roaming\Subversion\config, чтобы включить автоподдержку, и установил *.xml = svn:eol-style=native или даже *.xml = svn:eol-style=CRLF.

Однако, когда я пытаюсь импортировать это не помогает.

Я читал о RDC (Репозиторий диктует конфигурацию) . Все вспомогательные материалы и учебные пособия объясняют идею. Но как мне настроить это свойство на уровне хранилища.

Я могу установить это свойство как одноразовое (только для импорта файла дампа) и удалить его позже. Поэтому, когда пользователи фактически используют его, мне не нужно применять это.

Пожалуйста, помогите.

Answer 1

Спасибо Маркус. После тщательного кропотливого поиска я нашел решение. У импортера svi до polotion есть папка config.autoprops. У этого есть опция, чтобы установить стиль eol в этом. Установка этого и создание дампов SVN решили проблему

PS: ответил на это для моей будущей ссылки

Answer 2

Я бы пошел в обход Git, потому что я привык к этому (на самом деле, я просто придерживался Git - лично я считаю, что он значительно превосходит SVN):

• установить git-svn и git-cvs
• используйте git-cvs для импорта истории CVS
• использование sed, конвертируя все файлы, и git commit тот.
• используйте git-svn, чтобы отправить это в репозиторий SVN

РЕДАКТИРОВАТЬ: я забыл, что вы используете странную операционную систему для разработки, где не так просто установить стандартные инструменты. Согласно тому, что я могу догадаться на основании исходного кода, msysgit должен содержать возможности git-svn. Я не очень уверен насчет git-cvsimport. Возможно, будет проще всего использовать любой linux (может быть, просто использовать live DVD), на котором установлен git, и git-cvsimport, так что у вас есть история CVS в репозитории git, которую вы затем можете просто клонировать / использовать под windows.

Вы действительно должны прочитать руководство по миграции git/CVS (не волнуйтесь, не очень долго) - оно объясняет, чего вам не хватало, когда вы использовали CVS.

Также вы сказали, что переезд в SVN был корпоративным решением. Я мог бы критиковать вашу корпорацию за это, но это было бы бесполезно. Вместо этого я мог бы указать, что вы можете полностью соответствовать корпоративным правилам, используя git локально для отслеживания своих собственных ветвей, и переходить к корпоративному репозиторию SVN только тогда, когда материал является "общедоступным". В git очень распространено просто запустить ветку в вашем локальном репозитории, в которой вы разрабатываете новую функцию, или исправить определенную ошибку и т. Д., Затем убедиться, что все работает хорошо, и затем объединить ее с вашей основной веткой разработки, прежде чем нажимать эту ветку. в удаленный репозиторий. Git все делает за тебя, как обычно. Поэтому, даже если ваш коллега изменил основную ветку разработчика, когда вы работали над веткой функций, вы все равно сможете легко объединить ваши изменения с этим - честно говоря, в этом случае SVN намного хуже, что дополнительная работа, которую вы получаете, подготавливая свою историю git для публикации в SVN, легко компенсируется.

Я видел, как люди "предпочитают" SVN, а не git, потому что они утверждают, что git "слишком сложен". На самом деле это не так. Кроме того, люди, которые решили, что сотрудники должны использовать SVN в 2015 году, заслуживают разрешения конфликтов, которые вызывает SVN, когда два человека работают над различными функциями в одной ветви.