Как начать восстанавливать репозиторий

Question

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

$hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
 smartdox/application/helpers/common_helper.php@?: rev 1 points to unexpected changeset 10
 (expected )
 smartdox/application/helpers/common_helper.php@?: fbe7ec6785e5 not in manifests
 smartdox/application/libraries/MY_Model.php@?: rev 1 points to unexpected changeset 10
 (expected )
 smartdox/application/libraries/MY_Model.php@?: d84e95aff93f not in manifests
 smartdox/application/product_customizers/Proposals - CA Integrated/product.php@?: rev 1 points to unexpected changeset 2
 (expected 7)
 smartdox/application/product_customizers/Proposals - CA Specialty/custom.js@?: rev 1 points to unexpected changeset 2
 (expected 7)
 smartdox/application/product_customizers/Proposals - CA Specialty/product.php@?: rev 1 points to unexpected changeset 2
 (expected 7)
 smartdox/application/product_customizers/Proposals - GA Integrated/product.php@?: rev 1 points to unexpected changeset 2
 (expected 7)
 smartdox/application/product_customizers/Proposals - NY Combined/custom.js@?: rev 1 points to unexpected changeset 5
 (expected 10)
 smartdox/application/product_customizers/Proposals - NY Combined/custom.js@?: rev 2 points to unexpected changeset 6
 (expected 12)
 smartdox/application/product_customizers/Proposals - NY Combined/product.php@?: rev 1 points to unexpected changeset 2
 (expected 7)
 smartdox/application/views/help/training.php@?: rev 1 points to unexpected changeset 7
 (expected 6)
 smartdox/css/admin.css@?: rev 1 points to nonexistent changeset 26
 (expected )
 smartdox/css/admin.css@?: 5c92b2914085 not in manifests

Я знаю, что нам нужно воссоздать репозиторий, но мне нужно определить фактический источник проблемы, чтобы я знал, почему это происходит. У кого-нибудь есть мысли о том, как я могу исследовать / исправить эти проблемы? https://www.mercurial -scm.org / wiki / RepositoryCorruption не так полезен, как я бы надеялся ... он не описывает, что происходит с rev x points to unexpected changeset x

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

UPDATE

Мы верим, что проблема в самбе. Мы используем его для отображения дисков Linux на Windows, чтобы мы могли использовать Tortoise HG. Мы находимся в процессе поиска альтернативных решений.

Answer 1

Это никогда не происходит при обычном использовании. Большинство сайтов имеют репо в течение многих лет, даже не видя, как hg verify говорит что-либо.

Единственный раз, когда я видел это, было вызвано одним из:

• людей, удаляющих файлы слишком агрессивно. Например: find . -name '*.bak' | xargs rm. Это кажется действительно безопасным, но он удаляет файлы изнутри repo/.hg/store, который является зоной, не требующей доступа пользователя
• люди, изменяющие файлы слишком агрессивно. Например find repo -type f | xargs perl -pie 's/1999/2000'. Такое ощущение, что вы меняете 1999 на 2000 во всех файлах в рабочем каталоге, но вы снова включили repo/.hg/store и теперь ваши файлы повреждены
• людей, использующих любой механизм, отличный от hg push, pull, and clone, для перемещения изменений или наборов изменений с одного компьютера на другой.

Этот последний стоит другого списка. Любое из них подозрительно:

• репо на файловом сервере (особенно windows / smb) с hg на локальных машинах
• синхронизация каталогов .hg в стиле dropbox

Авторы Mercurial действительно усердно работают над тем, чтобы все исправить , когда вы работаете с репозиторием, находящимся на удаленном файловом сервере, но примитивы протоколов файлового сервера просто отсутствуют. Например, hg clone создает жесткие ссылки, которые поддерживает NTFS, а в локальных системах вызов get-link-count возвращает текущее число, даже если оно больше 1, но когда клиенты Windows запрашивают файлы, размещенные в NTFS, через некоторые версии smb Windows всегда возвращает счетчик ссылок, равный 1, что говорит Mercurial, что ни один другой клон не использует этот файл, поэтому его можно изменить без предварительного копирования.

Я думаю, что последний из них был исправлен в Mercurial, но основной императив заключается в том, что если по вашему сетевому кабелю приходят «изменения», инициируемые любой командой, кроме push, pull или клон, о котором вы мечтаете, и вам нужно принять распределенную природу DVCS и иметь действительно локальный клон.

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

Answer 2

будет эта ветка справки по списку рассылки Mercurial?