Исправлена ошибка проверки целостности в Mercurial?
Я только что сделал hg pull
в репозитории и внес несколько изменений. Он сказал, чтобы бежать hg update
, поэтому я и сделал. К сожалению, когда я это сделал, он провалился со следующим сообщением об ошибке:
abort: integrity check failed on 00manifest.i:173!
Когда я запускаю hg verify
, он говорит мне, что есть ряд проблем с вещами, не находящимися в манифесте (с некоторым небольшим скрытием пути):
>hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
somewhere1/[email protected]: in changeset but not in manifest
somewhere2/[email protected]: in changeset but not in manifest checking files
[email protected]: ee005cae8058 not in manifests
somewhere2/[email protected]: 00371c8b9d95 not in manifests
somewhere3/[email protected]: 5c921d9bf620 not in manifests
somewhere4/[email protected]: 23acbd0efd3a not in manifests
somewhere5/[email protected]: ce48ed795067 not in manifests
somewhere5/[email protected]: 15d13df4206f not in manifests
1328 files, 174 changesets, 3182 total revisions
8 integrity errors encountered!
(first damaged changeset appears to be 170)
Исходный репозиторий отлично передает hg verify
.
Есть ли способ восстановить сбой проверки целостности или мне нужно полностью повторить клонирование репозитория из источника (в этом случае это не громадная проблема)? Что я мог сделать, чтобы вызвать это, поэтому я не делаю этого снова?
Ответы
Ответ 1
Хорошо, так как первый поврежденный набор изменений - 170, вы можете клонировать ваш локальный репозиторий на 169, а затем вытащить из источника. Это означает только вытягивание 5 наборов изменений.
hg clone -r 169 damagedrepo fixedrepo
cd fixedreop
hg verify
И затем:
hg pull originalsource
Что касается ручного восстановления коррупции репозитория, эта страница излагает это лучше, чем я могу. См. Раздел 4.
Я искал коррупцию раз в то время раньше, и, хотя в приведенной выше документации говорится, что обычно это ошибка пользователя, мои экземпляры были на съемных USB-накопителях с пустыми рабочими каталогами. Иногда вещи просто не написаны правильно или каким-то образом мешают: это не всегда ошибка пользователя. Но у меня всегда есть несколько копий, которые я могу отменить, поэтому мне удалось уйти с базовой фиксацией.
Если простое исправление частичного локального клона и вытаскивание с сервера не исправляет его, вы можете отказаться от двух вариантов после резервного копирования ваших изменений (если они есть) в пакет или патчи:
- Вручную взломать файлы Mercurial.
- Выполнение нового полного клона с сервера. Обычно это проще и быстрее.
Ответ 2
Осторожно: этот метод изменит все хеши.
На самом деле есть другой способ восстановить хранилище, когда оно повреждено, как это -
Вы можете выполнить полную перестройку хранилища, используя расширение convert. См. Раздел 4.5 на https://www.mercurial-scm.org/wiki/RepositoryCorruption#Recovery_using_convert_extension
Сначала включите расширение для преобразования, добавив следующее в файл ~/.hgrc
[extensions]
convert=
Затем конвертируйте плохое репо, чтобы создать фиксированное репо:
$ hg convert --config convert.hg.ignoreerrors=True REPO REPOFIX
Это сработало для меня, когда я вдруг обнаружил, что в манифестах отсутствуют файлы - "ошибка 255".
Ответ 3
Попробуйте удалить файл 00manifest.i
из repo и затем использовать команды hg remove 00manifest.i
и hg commit
. Работал для меня.
Ответ 4
В результате мы создали новую копию нашего "центрального" репозитория, удалив папку .hg в этой копии, создав там новый репозиторий (hg init), а затем работаем с ним в качестве центрального репозитория.
Помните, что это только подходящее решение, если вам не нужна ваша история изменений, кроме как в качестве ссылки (чего у нас нет). Вы можете использовать старый центральный репозиторий для этой цели.