Mercurial застрял "в ожидании блокировки"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

lock:  free
wlock:  (66722s)

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

hg debuglocks -W

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

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

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

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

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

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

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

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