Исправить неудачную проверку целостности в Mercurial?

Question

Я только что сделал 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/file1.aspx@172: in changeset but not in manifest
 somewhere2/file1.pdf@170: in changeset but not in manifest checking files
 file3.csproj@172: ee005cae8058 not in manifests
 somewhere2/file1.pdf@171: 00371c8b9d95 not in manifests
 somewhere3/file1.ascx@170: 5c921d9bf620 not in manifests
 somewhere4/file1.ascx@172: 23acbd0efd3a not in manifests
 somewhere5/file1.aspx@170: ce48ed795067 not in manifests
 somewhere5/file2.aspx@171: 15d13df4206f not in manifests
1328 files, 174 changesets, 3182 total revisions
8 integrity errors encountered!
(first damaged changeset appears to be 170)

Исходный репозиторий проходит hg verify просто отлично.

Есть ли способ восстановления после сбоя проверки целостности, или мне нужно полностью клонировать репозиторий из источника (в данном случае это не большая проблема)? Что я мог сделать, чтобы вызвать это, чтобы я не делал это снова?

Answer 1

Ну, так как первый поврежденный набор изменений - 170, вы можете клонировать свой локальный репозиторий в 169, а затем извлечь из источника.Это означает только 5 изменений набора.

hg clone -r 169 damagedrepo fixedrepo
cd fixedreop
hg verify

И затем:

hg pull originalsource

Что касается ручного восстановления повреждения хранилища, эта страница объясняет это лучше, чем яМожно.See section 4.

Время от времени я обнаружил повреждение, и хотя в приведенной выше документации говорится, что обычно это происходит из-за ошибки пользователя, мои экземпляры были на съемных USB-накопителях с пустыми рабочими каталогами.Иногда вещи просто не пишутся правильно или им как-то мешают: это не всегда ошибка пользователя.Но у меня всегда есть несколько копий, с которых я могу отреагировать, поэтому я смог обойтись без базовых исправлений.

Если простое исправление частичного локального клона и извлечения с сервера не исправляетэто значит, что после резервного копирования изменений (если они есть) в пакет или исправления у вас остается до двух вариантов:

• Ручной взлом файлов Mercurial.
• Создание нового полного клонас сервера.Обычно легче и быстрее из двух.

Answer 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».

Answer 3

Попробуйте удалить ваш файл 00manifest.i из репозитория и в следующий раз использовать hg remove 00manifest.i и hg commit команды. Работал на меня.

Answer 4

В итоге мы сделали новую копию нашего «центрального» репозитория, удалили папку .hg в этой копии, создали там новый репозиторий (hg init), а затем работали с этим в качестве центрального репозитория.

Имейте в виду, однако, что это только подходящее решение, если вам не нужна история изменений, кроме как для справки (чего мы не делаем).Для этой цели вы все еще можете использовать свой старый центральный репозиторий.