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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

• .hg/магазин/phaseroots
• .hg/wlock

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

Ответ 7

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

Сегодня я получил "ожидание блокировки в репозитории" в команде 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, возможно, это может сделать базар DVCS). Я удивлен, что symlinked REP-ROOT/.hg работает вообще, хотя, похоже, кроме этого нажатия.

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

hg debuglock показал это: lock: free wlock: (66722s)

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

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