svnadmin: Svndiff содержит слишком большое окно - PullRequest
Новая
       7

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

3 голосов
/ 17 сентября 2010

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

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

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

Ответы [ 2 ]

4 голосов
/ 24 июля 2013

С тех пор, как я столкнулся с этим сегодня ...

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

РЕЗЕРВНОЕ КОПИРОВАНИЕ ВАШЕГО SVN-хранилища.

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

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

Если ваша база данных fsfs 'layout sharded', вам нужно получить 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 verify заново.Повторите описанный выше процесс для дальнейших ошибок.

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

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

Запустите проверку svnadmin еще раз!

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

0 голосов
/ 20 апреля 2011

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

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

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

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

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

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

Надеюсь, что это поможет, было очень трудно разобраться в этом вопросе.

...