Ошибка VisualSVN - в файле редакции отсутствует завершающий символ новой строки

Question

У нас установлен VisualSVN Server 2.1.3 на Windows Server 2003, и все клиентские машины используют клиент TortoiseSVN для фиксации и других операций SVN. До вчерашнего дня все работало нормально.

Вчера я совершил редакцию № 22181 ночью и покинул офис, и это последний коммит, который произошел со вчерашнего дня. Когда я попытался показать журнал сегодня или попытался обновить SVN, я получил эту ошибку:

Revision File Lacks Trailing Newline.

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

http://www.jamesstroud.com/jamess-miscellaneous-how-tos/os-x-admin/fix-svn-revision-file-lacks-trailing-newline

Хотя эта ссылка говорит о том, что эта ошибка возникает, когда размер коммита svn превышает 4 ГБ, но последний коммит, который я сделал, был едва ли 1 МБ. Я все еще выполнил вышеупомянутые шаги, упомянутые в посте, и после этого я смог сделать show log в хранилище, что является хорошим признаком, но затем я получил другую ошибку, когда попытался зафиксировать файл:

Cannot move tempfile.2.tmp to txn-current : the disk structure is corrupted.

Затем я отменил вышеуказанные изменения, когда вначале взял резервную копию и провел дополнительные исследования, и в соответствии с приведенной выше инструкцией мне пришло в голову, что проблема связана с последней ревизией, которую я зафиксировал вчера. Потом я попробовал svnadmin.exe используя командную строку и команду dump для создания файла дампа между ревизиями 1-22180, но был поражен, увидев, что мой сервер завис, поскольку, возможно, размер создаваемого дампа был больше размера диска, на котором я сохранял файл дампа, Моим мотивом создания дампа было сбросить все ревизии, кроме последней, то есть 22181, а затем создать новый репозиторий и загрузить файл дампа, и это могло бы решить проблему. А потом я прочитал, что если мы укажем конкретные ревизии в команде dump, это займет больше места, чем дамп, созданный для всей базы данных. Но если взять дамп всей базы данных, как мне удалить последнюю ревизию из файла полного дампа?

Если вы хотите узнать команду svnadmin, которую я выполнил, то вот она:svnadmin.exe dump –r 1-9 F:\svn-repo > C:\Tempdump.dmp

Теперь я пытаюсь использовать команду проверки после публикации этого сообщения.

Пожалуйста, помогите мне решить эту проблему, так как я устала, и завтра наши сотрудники не смогут работать без svn-операций, поскольку это очень важно. Размер нашего репозитория SVN составляет около 35 ГБ, и я думаю, что если мне придется использовать команду дампа, мне придется подключить жесткий диск USB, чтобы сохранить файл дампа, поскольку на диске сервера, который имеет максимальное пространство, является диск C с 48 ГБ пространства.

Я не уверен, каково реальное решение. Пожалуйста, помогите и спасибо, что читаете все.

Спасибо

Answer 1

1. Хранилище повреждено, у вас есть резервная копия для восстановления? Восстановление хранилища из резервной копии будет лучшим решением.

   Вообще говоря, имеет смысл запустить svnadmin verify для каждого хранилища на устройстве хранения, чтобы проверить его на наличие повреждений. Увидеть svnadmin verify ссылка на командную строку.

   Обратите внимание, что похоже, что запоминающее устройство (HDD?) Было повреждено в ночь, когда вы зафиксировали ревизию 22181, я настоятельно рекомендую проверить ее на наличие ошибок, используя chkdsk инструмент и замена его при необходимости. Увидеть chkdsk ссылка на инструмент.

2. Ожидается, что свалка производится svnadmin dump (используя настройки по умолчанию) больше, чем хранилище на диске. Если вы хотите уменьшить размер ревизии 0-22180, используйте параметр --deltas.

   Смотрите SVNBook | Миграция репозитория с использованием svnadmin:

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

Answer 2

Я обнаружил, что эта проблема не относится к Windows или Linux. Вот предыстория того, как я столкнулся с этой проблемой. У меня есть старый дистрибутив Linux на моем сервере разработки, и я не обновлял его годами, обновлять gentoo очень сложно, поэтому я хотел убедиться, что я могу перенести репозиторий SVN на последний SVN, прежде чем стирать сервер и переустанавливать, Старому SVN исполнилось 1.8.11. Новый SVN довольно недавний 1.9.5. Разница в версиях составляет 4 года.

Итак, я упомяну, как я это исправил в Linux.

svnadmin dump <old repo path> > SVN-Repo.dump

Затем на новом сервере с новым установленным сервером SVN после создания хранилища SVN:

mkdir -p <new repo path>
svnadmin create <new repo path>

Затем установите любые необходимые вам разрешения.

Запустите команду:

svnadmin load --force-uuid <new repo path> < SVN-Repo.dump

И для меня это решает проблему.

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

Например, если я создаю новый SVN-репозиторий в моей старой версии, а затем скопирую его в новую версию SVN, произойдет сбой с той же ошибкой. И все же не было времени на то, чтобы быть испорченным. Кроме того, для меня, когда я пытался использовать новый SVN в старых файлах репозиториев SVN, он показал, что 2-й последний коммит (661) был в порядке, а последний (662) - поврежденным. Когда я удалил последний коммит (662), а затем попытался снова, он показал новый последний коммит (661) как поврежденный, хотя ранее сообщалось, что этот коммит был в порядке. Эти ошибки были замечены в проверке svnadmin. Это наводит меня на мысль, что это нижний колонтитул ниже истории ревизий, который не читается, и что с самим репозиторием все в порядке.

Когда мы делаем дамп по какой-либо причине, нижний колонтитул больше не вызывает никаких проблем. Либо потому, что его там нет, либо более устойчиво обратно совместимо, либо потому, что его игнорируют.

Поэтому, если возможно - не уверен, что вы можете сделать это под Windows, но я подозреваю, что вы можете, взять дамп SVN старого репозитория и просто импортировать дамп в новый репо. Возможно ли, что ваш SVN был обновлен, и это вызвало проблему, как это было с моим?