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

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

После перезагрузки я теперь получаю это сообщение почти для всех команд 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 не поможет.

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

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

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

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

У меня была эта проблема без обнаруживаемой блокировки файлов. Я нашел решение здесь: 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 за то, что они не документируют блокировки должным образом; б) не ставить метки времени для автоматического удаления, когда они устаревают.

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

• удалить файл .hg/store/lock(согласно принятому ответу )
• удалить файл .hg/store/phaseroots(согласно отчету об ошибке TortoiseHG )

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

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

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

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

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

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

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

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

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

Сегодня я получил "ожидание блокировки в хранилище" по команде 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 работает вообще, хотя, кажется, за исключением этого толчка.

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

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

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

lock:  free
wlock:  (66722s)

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

hg debuglocks -W

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

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

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

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

Если это происходит только на подключенных дисках, это может быть ошибка https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share . Использование пути UNC вместо буквы диска, кажется, обходит проблему.