На домашнем сервере произошел сбой жесткого диска.
Как только я понял, что диск работает, я вошел в систему и сделал прямую копию своего хранилища, содержащего несколько проектов.
Однако, поскольку диск вышел из строя, одна из ревизий повреждена:
$ svnadmin verify master/
[...]
* Verified revision 820.
* Verified revision 821.
* Verified revision 822.
svnadmin: No such revision 823
Каталоги master/db/revs/ и master/db/revprops/ действительно не содержат файлов с именем 823, поэтому эта редакция отсутствует (не работает). В репозитории master/ есть последующие ревизии (которые я действительно хочу сохранить!) Вплоть до ревизии # 947.
Сегодня я получил свою самую последнюю резервную копию (!), Которая включает эту ревизию. Я хотел бы "исцелить" поврежденный репозиторий в master/, исправив отсутствующую ревизию, поскольку она более поздняя, чем резервная копия.
Я удостоверился, что загрузил файл дампа во вновь созданный репозиторий с той же версией, что и скопированный в master/, так что это все старый "линейный" формат 3.
Я попробовал очевидное, просто скопировав файл 823 из резервной копии каталогов db/revs/ и db/revprops/:
$ cp repos/db/revs/0/823 master/db/revs/
$ cp repos/db/revprops/0/823 master/db/revprops/
Каталог repos/ содержит хранилище, которое было загружено из резервной копии. Теперь я получаю:
$ svnadmin verify master/
[...]
* Verified revision 821.
* Verified revision 822.
svnadmin: /build/buildd/subversion-1.6.12dfsg/subversion/libsvn_delta/compose_delta.c:165: search_offset_index: Assertion `offset < ndx->offs[ndx->length]' failed.
Aborted
Что не очень обнадеживает. Я пробовал различные другие svnadmin команды, но ни одна не порадовала верификатора.
Моей следующей идеей было отказаться от копирования и начать со «свежей» копии испорченного репозитория, затем выгрузить ревизии после 823 и объединить с резервной копией. Но это не представляется возможным, я не могу выбросить ревизии после пропущенной:
$ svnadmin dump -r 824 master/ >r824.dmp
svnadmin: No such revision 823
Обратите внимание, что это не помогает сделать дамп "инкрементным", в надежде, что он должен притвориться, что мир начался с ревизии 824 и просто перейти оттуда:
$ svnadmin dump --incremental -r 824:947 master/ > dump.txt
svnadmin: No such revision 823
Это записывает вывод в dump.txt, но я не уверен, что на него можно положиться. Обратите внимание, что он не регистрирует, что он успешно сбросил любую ревизию.
Обновление : у меня была другая идея: скопировать более новые файлы редакции из аварийного диска-копии в master/ в резервную копию, чтобы предоставить «отсутствующий хвост»:
$ for a in $(seq 910 947) ; do cp master/db/revs/$a repos/db/revs ; cp master/db/revprops/$a repos/db/revprops/ ; echo $a ; done
Однако, похоже, это не делает ничего, кроме повреждения целевого хранилища:
$ svnadmin verify repos/
[...]
* Verified revision 907.
* Verified revision 908.
* Verified revision 909.
svnadmin: Corrupt representation '907 21815 45 30922 158d3e72732f45bf6f02919b22fc899a'
svnadmin: Malformed representation header
Теперь у меня закончились идеи.