svnadmin: Svndiff содержит слишком большое окно

Так как я столкнулся с этим сегодня...

Вероятно, в вашем репозитории svn с базой данных FSFS есть поврежденная версия.

СДЕЛАЙТЕ РЕПОЗИТОРИЮ SVN.

Определите, упакован ли ваш репозиторий, прочитав ${REPO}/db/format

[root@chi2 db]# cat format
4
layout linear

Если ваша база данных fsfs «раздроблена по макету», вам необходимо получить файл fsfs-reshard.py отсюда: http://ymartin59.free.fr/wordpress/wp-content/2010/07/fsfs-reshard.py

(Эта версия работает с репозиториями 1.6+, а патч этого парня до сих пор не портирован на магистраль svn).

Запустите следующее, чтобы распаковать репозиторий:

./fsfs-reshard.py ${REPO} 0

Запустите проверку:

svnadmin verify ${REPO}

* Verified revision 13689.
* Verified revision 13690.
* Verified revision 13691.
svnadmin: E185001: Svndiff contains a too-large window

Ревизия, в которой была обнаружена ошибка, была на 1 больше, чем последняя проверенная версия, наша плохая версия — 13692.

Получите файл fsfsverify.py из магистрали Subversion. http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/fsfsverify.py

Запустите fsfsverify.py для вашей плохой версии. Возможно, вам придется запустить параметр -f два или более раз. Это выдаст много данных, но в конечном итоге они должны быть чистыми.

[root@chi2 archive]# ./fsfsverify.py -f ${REPO}/db/revs/13692
Copy 4640123 bytes from offset 1006867
Write 4640123 bytes at offset 1003542
Fixed? :-)  Re-run fsfsverify without the -f option
[root@chi2 archive]# ./fsfsverify.py ${REPO}/db/revs/13692

Запустите проверку svnadmin еще раз. Повторите описанный выше процесс для любых других плохих версий.

Получив проверенный репозиторий, вы можете переупаковать его, запустив

./fsfs-reshard.py ${REPO} 1000

Запустите svnadmin verify еще раз!

Ваш репозиторий SVN должен быть в порядке!

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

Файлы в SVN записываются по имени И их хэшу файла (я полагаю, что они MD5). Если вы удалите файл, а затем снова попытаетесь загрузить тот же файл, SVN запомнит хэш и вместо создания нового базового дельта-файла укажет на предыдущую версию, в которой он существовал.

В какой-то момент жизни вашего репозитория ваш файл стал «отравлен». Любые файлы, которые соответствуют MD5 вашего файла (независимо от пути фиксации), не пройдут процесс svndiff (по причинам, до сих пор не совсем ясным), потому что SVN пытается использовать старую и сломанную версию. Если вы хотите «исправить» проблему, измените файл локально (если это код, попробуйте добавить пустой комментарий), и это приведет к изменению MD5. После удаления файла и фиксации новой «исправленной» версии служба должна возобновиться в обычном режиме.

Теперь вернемся к моему первому абзацу — это решение действительно будет работать только с файлами, которые вы можете позволить себе изменить. Если, например, у вас есть видеофайл размером 100 МБ, то вам нужно будет его как-то модифицировать, чтобы изменить хэш. Еще хуже, если вы работаете с исполняемыми файлами, так как они, как известно, трудно модифицируются после компиляции.

Моя рекомендация будет следующей:

• Если это текстовый файл, попробуйте сделать косметические возможности (например, пустые комментарии, дополнительный перевод строки и т. д.).
• Если это исполняемый двоичный файл, попробуйте перекомпилировать его.
• Для всех других двоичных файлов (изображений, видео и т. д.) вам нужно будет проявить изобретательность в том, как вы их модифицируете.

Я надеюсь, что это чем-то поможет, это была настоящая боль, чтобы добраться до сути этой проблемы.