Восстановить поврежденный репозиторий SVN

Я использую svnX (0.9.13) на Mac OS X Lion (10.7.2 11C74) и, похоже, имею, что я считаю, это поврежденный репозиторий SVN. Я искал сайт для подобных вопросов инашел a пара, но никто не описывает, как восстановить, когда вы не можете завершить оформить заказ из репозитория. У меня также нет обновленного рабочего каталога.

ошибки:

svn: несоответствие контрольной суммы при чтении представления:
ожидалось: [хэш]
фактический: [разные хэш]

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

любые предложения о том, как действовать, будут оценены.

2 ответов


когда у вас есть поврежденный репозиторий, ваш единственный реальный шанс сохранить информацию-сделать дамп и загрузить. Если Вам ПОВЕЗЕТ, выполнение дампа и загрузки иногда исправит повреждение.

Если нет, вы можете использовать -r <from>:<to> параметр на дампе, чтобы пропустить плохие ревизии. Вы можете создать несколько файлов дампа и объединить их в один репозиторий, чтобы пропустить плохие номера версий. Я заметил, что каждый файл дампа начинается с полного пересмотра репозиторий в этой ревизии, и процесс дампа / загрузки обычно достаточно умен, чтобы не удвоить изменения.

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

$ svnadmin dump -r1:1000 my_repos > dumpfile.txt
$ svnadmin dump --incremental -r1002:1203 my_repos >> dumpfile.txt
$ svnadmin dump --incremental -r1205:HEAD my_repos >> dumpfile.txt
$ svnadmin load my_repos2 < dumpfile.txt

существует несколько сценариев резервного копирования Subversion, которые создают резервную копию репозитория, принимая дампы новейших версий. Например, при первом запуске он сбрасывает все от первой редакции до последней версии (скажем пересмотре 1000). Затем на следующий день он сбрасывает ревизию 1001 до последней редакции (скажем, 1003), а на следующий день ревизию 1004 до последней редакции.

чтобы восстановить, Вы должны восстановить все дампы, но время резервного копирования должно быть короче, чем делать полный дамп каждый раз.

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


вы должны сделать дамп и загрузить, как предложил Дэвид У. Однако существует несколько подводных камней с которыми я столкнулся и хотел бы опубликовать полное решение.

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

Сначала мы попробуем отключить расчет контрольной суммы, удалив строки, соответствующие Text-content-md5

svnadmin dump my_repo | sed '/^Text-content-md5/d' | svnadmin load second_repo

поэтапный подход позволяет исправлять ошибки и продолжать прогресс. Если во время дампа и загрузки произошла ошибка, найдите последнее --- Committed revision X >>> --- сообщение и поместите X+1 в качестве начальной версии в качестве параметра-r и повторите попытку. Это экономит значительное время.

svnadmin dump --incremental -r1:100000 my_repo | sed '/^Text-content-md5/d' | svnadmin load second_repo

или просто загрузить из файла dumpfile:

sed '/^Text-content-md5/d' dumpfile.txt | svnadmin load second_repo

если этого было недостаточно, и вы получаете ошибку "преждевременный конец данных контента в dumpstream" или что-то подобное, вы должны полностью исключить этот файл из дампа svndumpfilter:

svnadmin dump --incremental -r1:100000 my_repo | svndumpfilter exclude myproject/lib/thirdparty-all.jar | sed '/^Text-content-md5/d' | svnadmin load second_repo

команда выше исключает myproject/lib/thirdparty-all.jar файл из дампа.

дополнительная информация:

  • вы могли бы добавить --bypass-prop-validation to . Это работает, если коррупция незначительна.
  • исправить Dump stream contains a malformed header (with no ':') ошибка с добавлением
    | grep --binary-files=text -v '^* Dumped revision'
    к Трубной цепи (до svnadmin load).

надеюсь, что этот пост полезен для некоторых людей.