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

Question

Когда я пытаюсь загрузить/восстановить свои SVN репозитории, я получаю ошибку:

svnadmin: Svndiff contains a too large window

Как я могу решить эту проблему?

Answer 1

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

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

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

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

Моя рекомендация будет выглядеть следующим образом:

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

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

Answer 2

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

Существует вероятность испорченный ревизии в репозиторий SVN с базой данных FSFS.

РЕЗЕРВНОЕ КОПИРОВАНИЕ.

Определить, если хранилище упаковано/sharded чтения $ {} РЕПО/дб/формат

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

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

(Это версия работает на 1,6+ более крупных репозиториях, и патч этого парня по-прежнему не был перенесен на svn trunk).

Выполните следующие действия, чтобы распаковать архив:

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

Run проверить:

svnadmin verify ${REPO} 

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

ревизии, было ошибочной из был пересмотром-больше, чем последняя проверенной ревизия, наш плохой оборот составляет 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 464bytes from offset 1006867 
Write 464bytes 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 

Run svnadmin еще раз проверить!

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