Как исправить ошибку окончания строки импорта SVN?

Question

Мне нужно импортировать огромный репозиторий SVN, который мне нужно передать с одного сервера на другой. Поэтому я экспортировал его от старого сервера:

svnadmin dump . > archive.svn 

и импортировать его на новый:

svnadmin load . < archive.svn 

В середине процесса импорта я получил эту ошибку:

Cannot accept non-LF line endings in 'svn:ignore' property 

Как я могу это исправить? У меня есть полный контроль над обоими серверами.

Answer 1

Вы изменили версию сервера? Это известная проблема в версии 1.6 и вызывает проблемы при переходе от 1.4 или 1.5.

Subversion 1.6 больше не принимает возврат каретки (^ M) в файлах свойств. Вам нужно будет исправить разрывы строк в файле svn: ignore или просмотреть, если это проще.

В качестве альтернативы, вы можете пойти за Subversion 1.7 или использовать uberSVN.

Answer 2

У вас есть 2 варианта, исправьте источник или отключите проверку прокрутки.

Ремонт источник (SVN: журнал и SVN: игнорировать):

sed -e '/^svn:log$/,/^K/s/^M/ /' -e '/^svn:ignore$/,/^PROPS-END$/ s/^M/\n/' archive.svn > repaired-archive.svn 

svnadmin load . < repaired-archive.svn 

Где ^M является управляющим символом, это означает, что 0D в шестнадцатеричном формате. Для того, чтобы получить его использовать^V^M (контроль управления V M) вместо^M (огибающая M или управление M)

Отключение проп проверки:

svnadmin load --bypass-prop-validation . < archive.svn 

Answer 3

Я столкнулся с этой ошибкой при обновлении 1,6 репо до 1,8. Я нашел ряд «исправлений» в сети.

-bypass-prop-validation не понравился мне, потому что он откладывает проблему, в следующий раз, когда вам нужно восстановить репо, вы попадете в ту же проспект.

Я нашел сценарий bash, чтобы перебирать версии, получая комментарии и настраивая их снова, но это не сработало.

Улучшение решения ventura10 выполнило эту работу. Из-за размера свалки я в конечном итоге с помощью одной команды, чтобы удалить ненужные символы при восстановлении дамп

sed -e '/^svn:log$/,/^K/s/^M/ /' -e '/^svn:ignore$/,/^PROPS-END$/ s/^M/\n/' /path/to/svn.dump | svnadmin load /path/to/repo 

Примечание:

Where ^M is a control character, that means 0D in hex. To get it use ^V^M (control V control M) instead ^M (circumflex M or control M)

Answer 4

Первый вариант ответа @ ventura10 звучал хорошо но не работает для меня. Команда sed изменила некоторые версии для версии вне раздела свойств, что привело к несоответствиям md5 при загрузке дампа.

Поскольку у моего репозитория нет свойств с двоичным содержимым, я изменил команду sed, чтобы исправить все свойства, а не только svn:log и svn:ignore. Я также был уверен, что ни один файл с версией не содержал строку, начинающуюся с Prop-content-length:. В противном случае у меня возникла бы ошибка при загрузке дампа.

sed -e '/^Prop-content-length: /,/^PROPS-END$/ s/^M/ /' svn.dump > svn.dump.repaired 

Это важно заменить ^M с [blank], так как размер стоимости имущества не должно измениться.

Нота @ ventura10 остается в силе:

^M is a control character, that means 0D in hex. To get it use ^V^M (control V control M) instead ^M (circumflex M or control M)

Это трудно поверить, что модернизация существующего хранилища из SVN 1.4 до SVN 1.7 делает этот шаг nessecary, но я не нашел никакого другого способа чтобы избавиться от возвратов каретки, которые больше не принимаются с момента svn 1.6.

Answer 5

Использование svndumptool:

svndumptool.py eolfix-prop svn:ignore svn.dump svn.dump.repaired 

решение @tangens тоже работает для меня, но это не так совершенно, как я получаю дополнительный пробел в качестве замены символов возврата каретки. Тем не менее, я тестировал, что svn: ignore все еще работает с этим дополнительным пространством, но я не тестировал другие свойства SVN.

Недостатком использования svndumptool является то, что он может работать только с одним свойством svn за один раз, что требует много времени, если ваши файлы дампа большие.

---

Некоторые выводы

Вы могли бы быть интересно, почему @tangens не заменит^М с пустым характером. Если попытаться заменить его пустой символ, вы будете получать эту ошибку:

svnadmin: E140001: Dumpstream data appears to be malformed 

свалка файл хранит Prop-content-length собственности, которые будут сопоставлены с содержанием фактического содержания имущества. Замена^M на пустой символ уменьшит длину содержимого свойства, а значит и ошибку.

svndumptool изменит Prop-content-length и Content-length соответственно.

Answer 6

С небольшой гимнастикой вы можете обойти это, используя svnsync, который имеет возможность исправить EOL. Предположим, что ваш репозиторий сброшен в archive.svn.

Сначала создайте хранилище для загрузки репо обратно, не обращая внимания на проблемы EOL:

svnadmin create repo 
svnadmin load repo < archive.svn --bypass-prop-validation 

Теперь создать новое хранилище для копирования в:

svnadmin create repo-fixed 

svnsync требует некоторых предварительно совершить крюк, даже если вы его не используете, просто используйте свой редактор для создания пустого в repo-fixed/hooks/pre-revprop-change:

#!/bin/sh 
exit 0 

Инициализировать хранилище назначения для svnsync:

svnsync init file:///path/to/repo-fixed file:///path/to/repo 

Теперь скопируйте весь репозиторий через:

svnsync sync file:///path/to/repo-fixed 

Уф! svnsync даже дать вам хорошие новости: (. Почему команда Subversion не обновлялись svnadmin сделать то же нормализацию является для меня загадкой) NOTE: Normalized svn:* properties to LF line endings

После того, как это сделано, дамп новый репозиторий:

svnadmin dump repo-fixed > archive-fixed.svn 

У вас теперь есть archive-fixed.svn, который должен быть идентичным archive.svn, за исключением того, что EOLs были исправлены по мере необходимости.

(Необязательно) Вы можете теперь удалить временный репозиторий, использованный для svnsync:

rm -rf repo-fixed 

Update Оказывается, если вы загрузите этот новый дамп, клиент Subversion получает ошибку: Repository UUID does not match expected UUID , Вам нужно будет использовать svnadmin setuuid ... до change the UUID ID to what it used to be.

(Это сообщение является кульминацией множества фрагментов и частичных решений, я нашел вокруг сети Спасибо всем, кто знал больше, чем я;. Я просто все это вместе.)

Смотрите также :

• Copying subversion repositories with history using svnsync
• https://stackoverflow.com/a/28472420/421049
• https://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt

Answer 7

Я только что удалил файл svn dump. Он также имел CRLF в свойствах, что вызвало исключение из импорта дампа SVN Edge (у них очень плохая процедура импорта). Тогда я «установил» Svnserve для тестирования, которое было намного легче, чем ожидалось (инструкции для ОС Windows):

1. загрузить и установить TortoiseSVN или другое программное обеспечение, которое включает в себя Svn инструменты командной строки. Я уже установил его
2. начало cmd.exe, пробег svnserve -d.Теперь это cmd-окно занято.
3. начать другой cmd.exe создать репозиторий: svnadmin create d:\svn_repos\test12
4. нагрузку на свалку в репо: svnadmin load d:\svn_repos\test12 < d:\temp\svn\backup_test.dump

Svnserve даст вам подробную информацию, что не удалось.

А вот то, что вам нужно отремонтировать (оригинал на левом, отремонтировали на правой стороне):