Меркурий застрял "в ожидании блокировки"

346

Получил синий экран в окнах при клонировании ртутного хранилища.

После перезагрузки я теперь получаю это сообщение почти для всех команд hg:

c: \ src \> hg commit
ожидание блокировки в репозитории c: \ src \ McVrsServer, удерживаемом '\ x00 \ x00 \ x00 \ x00 \ x00 \
x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00'
прерванный!

Google не поможет.

Какие-нибудь советы?

JM.
источник
3
Вау, у меня также был синий экран во время совершения, и я получил ту же ошибку. Рад, что я не единственный!
CBarr
3
Я предложил более эффективную обратную связь с сообщением об ошибке на сайте bz.selenic.com/show_bug.cgi?id=4752
Карл Рихтер,

Ответы:

489

При «ожидании блокировки на хранилище» удалите файл хранилища: .hg/wlock(или он может быть в .hg/store/lock)

При удалении файла блокировки вы должны убедиться, что ничто другое не обращается к хранилищу. (Если блокировка представляет собой строку нулей или пробел, это почти наверняка верно).

JM.
источник
103
Моя проблема не имела ничего общего с клонированием или BSOD, но я удалил файл .hg / wlock, чтобы снять блокировку.
Фрэнк Гаддер
32
hg recoverдолжен быть запущен после сломанной ситуации блокировки.
Джеймс Бродхед
9
Большое спасибо - после удаления .hg / wlock я понятия не имел, в чем проблема
Эндрю Басс
34
В моем случае (TortoiseHg V2.9.2 с Mercurial 2.7.2) имя файла было «wlock» вместо «lock»; и он был помещен в каталог ".hg", а не в ".hg / store".
Фернандо,
7
@Marmoute - хранилище блокируется всякий раз, когда будет произведено изменение. Если что-то приводит к сбою этого процесса - например, ошибка в Mercurial, сбой машины и т. Д. - файлы блокировки остаются, а не очищаются. Я полагаю, что предложения по удалению файлов блокировки вручную относятся к тем случаям, когда хранилище каким-то образом оставалось в «нечистом» состоянии. Назвать это «слепым снятием меркуриальной защиты» не является ни справедливой, ни точной характеристикой того, что происходит в этих случаях.
JoGusto
345

Когда waiting for lock on working directoryудалите .hg/wlock.

Тьяго Матос
источник
6
Это был случай для меня. Это была символическая ссылка 'nix на текущий server:pid. Огромное спасибо. Затем мне пришлось бежать, $ hg recoverчтобы очистить существующий журнал (и сообщение коммита), который я ctrl+cредактировал. Не уверен, но вы можете запустить $ hg recoverбез удаления файла блокировки, и он сделает это за вас. Полагаю, стоит попробовать.
Шолзингер
2
Просто обратите внимание, что @sholsinger скажет, что запуск hg recovery не сработает, если вы сначала не удалите блокировку. Я попробовал это.
Дан
1
Репозиторий заблокирован по причине, другой процесс работает над репо. Вы должны найти этот процесс и завершить его, вместо того чтобы слепо снимать ртутную защиту. Простое удаление файла может привести к повреждению хранилища.
Мармут
@ Marmoute В моем случае мне пришлось снять блокировку, потому что никакой другой процесс не работал на репо. Но я согласен, стоит сначала поискать другой процесс
Mi-La
Я получил это сообщение внезапно, когда пытался потянуть, после того, как потянул и толкнул в течение нескольких дней без проблем. После удаления файла проблема была решена. Файл был размером 0 КБ, что означает, что он был пуст. Можно ли просто удалить файл? Я думаю, это полезно для защиты.
Бен Карп
47

У меня была эта проблема без обнаруживаемой блокировки файлов. Я нашел решение здесь: http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError

Вот расшифровка стенограммы из консоли Tortoise Hg Workbench

% hg debuglocks
lock:  user None, process 7168, host HPv32 (114213199s)
wlock: free
[command returned code 1 Sat Jan 07 18:00:18 2017]
% hg debuglocks --force-lock
[command completed successfully Sat Jan 07 18:03:15 2017]
cmdserver: Process crashed
PaniniDev% hg debuglocks
% hg debuglocks
lock:  free
wlock: free
[command completed successfully Sat Jan 07 18:03:30 2017]

После этого прерванная тяга прошла успешно.

Блокировка была установлена ​​более 2 лет назад процессом, который отсутствует в локальной сети. Позор разработчикам hg за то, что они не документируют блокировки должным образом; б) не ставить метки времени для автоматического удаления, когда они устаревают.

Томас Шарплесс
источник
23
Подсказка: если wlockтот заперт, используйтеhg debuglocks --force-wlock
Брэд Турек
5
Я использовал черепаху HG в течение 7 лет. Я никогда не видел проблемы, пока около 3 месяцев назад. Я видел это 3 раза за последние 3 месяца. Некоторое обновление должно усугубить проблему.
d EI
20

У Coworker была именно эта проблема сегодня, после BSoD, когда он пытался оттолкнуться. Он должен был:

Затем его репо снова заработало.

РЕДАКТИРОВАТЬ: Согласно комментарию @ Marmoute - при работе с проблемами, связанными с блокировкой, использование hg debuglockявляется более безопасной альтернативой слепому удалению .hg/store/lockфайла.

Ян Кемп
источник
2
1) Абсолютно нет причин, по которым вам следует обращаться к файлу Pharoroots, он абсолютно не связан с блокировкой. 2) Слепое удаление часов - плохая идея, скорее всего, другой процесс использует его. используйте hg debuglock, чтобы выяснить, что происходит, и завершите процесс, удерживающий блокировку
Marmoute
3
1) Учитывая, что устранение проблемы решило проблему, я бы не согласился. 2) В то время не знал о hg debuglock (также не могу найти никакой документации по нему), и поскольку система только что вышла из перезагрузки, очевидно, что ничего не блокировало репозиторий - следовательно, удаление файла блокировки было уместно.
Ян Кемп
12

Я очень хорошо знаком с кодом блокировки Mercurial (по состоянию на 1.9.1). Приведенный выше совет хорош, но я бы добавил, что:

  1. Я видел это в дикой природе, но редко и только на машинах Windows.
  2. Удаление файлов блокировки - это самое простое решение, НО вы должны убедиться, что больше ничего не обращаются к хранилищу. (Если блокировка представляет собой строку нулей, это почти наверняка верно).

(Для любопытных: я еще не смог уловить причину этой проблемы, но подозреваю, что это либо более старая версия Mercurial, обращающаяся к хранилищу, либо проблема в вызове Python socket.gethostname () в некоторых версиях Windows.)

Брэд О
источник
2
FWIW это только что случилось со мной на Ubuntu. Я впервые использовал хранилище за несколько недель, поэтому я не помню, что могло бы оставить его в таком состоянии.
Cosmologicon
7

У меня была такая же проблема на Win 7. Решением было удалить следующие файлы:

  1. .hg / магазин / phaseroots
  2. .hg / wlock

Что касается .hg / store / lock - такого файла не было.

Иван Дулов
источник
Добро пожаловать в Stackoverflow. Попробуйте добавить больше контента к посту
NJInamdar
5
1) Абсолютно нет причин, по которым вам следует обращаться к файлу Pharoroots, он абсолютно не связан с блокировкой. 2) Слепое удаление часов - плохая идея, скорее всего, другой процесс использует его. используйте, hg debuglockчтобы выяснить, что происходит, и завершите процесс, удерживающий блокировку.
Marmoute
6

Я не ожидаю, что это будет выигрышный ответ, но это довольно необычная ситуация. Упоминание на случай, если кто-то кроме меня столкнется с этим.

Сегодня я получил "ожидание блокировки в хранилище" по команде hg push.

Когда я убил зависшую команду hg, я не увидел .hg / store / lock

Когда я искал .hg / store / lock, пока команда зависла, она существовала. Но файл блокировки был удален, когда была убита команда hg.

Когда я подошел к цели толчка и выполнил hg pull, проблем не возникло.

В конце концов я понял, что идентификатор процесса на hg push был сообщением об ожидании блокировки, которое каждый раз менялось. Оказывается, что «hg push» зависал в ожидании блокировки, удерживаемой самой собой (или, возможно, подпроцесса, я больше не исследовал).

Оказывается, что два рабочих пространства, назовем их A и B, имели деревья .hg, общие для symlink:

A/.hg --symlinked-to--> B/.hg

Это НЕ хорошая вещь, чтобы сделать с Mercurial. Mercurial не понимает концепцию двух рабочих пространств, совместно использующих один и тот же репозиторий. Однако я понимаю, как кто-то может прийти в Mercurial из другой VCS (это может сделать Perforce, хотя не DVCS; как сообщается, это может сделать Bazaar DVCS). Я удивлен, что символическая ссылка REP-ROOT / .hg работает вообще, хотя, кажется, за исключением этого толчка.

Крейзи Глеу
источник
Hg не отслеживает dirstate .hg/? Когда вы говорите, что репозитории «работают», не работает ли hg upв одном из них синхронизация dirstate в другом - или mercurial делает что-то особенное для поддержки этого?
binki
1
Вы можете использовать расширение общего ресурса (поставляется с Core Mercurial), чтобы иметь несколько рабочих каталогов из одного репозитория.
Marmoute
4

У меня такая же проблема. Получил следующее сообщение, когда я попытался зафиксировать:

waiting for lock on working directory of <MyProject> held by '...'

hg debuglock показал это:

lock:  free
wlock:  (66722s)

Поэтому я выполнил следующую команду, и это решило проблему для меня:

hg debuglocks -W

Использование Win7 и TortoiseHg 4.8.7.

user10125940
источник
2

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

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

markpasc
источник
2

Я столкнулся с этой проблемой в Mac OS X 10.7.5 и Mercurial 2.6.2 при попытке нажать. После обновления до Mercurial 3.2.1 я получил «никаких изменений не найдено» вместо «ожидания блокировки на хранилище». Я обнаружил, что каким-то образом путь по умолчанию был настроен так, чтобы он указывал на тот же репозиторий, поэтому неудивительно, что Mercurial запутается.

JWWalker
источник
1
Я обнаружил, что каким-то образом заданный по умолчанию путь указывает на тот же репозиторий . Это. Спасибо, вы - я прошел через петли, чтобы избавиться от проблемы, и pathнастройка была виновником.
WoJ