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

При "ожидании блокировки репозитория" удалите файл репозитория: .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 console

% 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 лет назад, с помощью процесса на машине, которая больше не находится на LAN. Позор разработчикам hg за то, что они а) не документируют замки должным образом; б) не помечают их для автоматического удаления, когда они становятся устаревшими.

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

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

Затем его РЕПО снова заработало.

EDIT: согласно комментарию @Marmoute's - при решении проблем, связанных с блокировкой, использование hg debuglock является более безопасной альтернативой слепому удалению файла .hg/store/lock .

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

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

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

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

1. hg/store/phaseroots
2. .hg/wlock

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

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

Сегодня я получил "waiting for lock on repository" по команде HG push.

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

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

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

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

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

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

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

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

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

Я столкнулся с этой проблемой на Mac OS X 10.7.5 и Mercurial 2.6.2 при попытке нажать. После обновления до Mercurial 3.2.1 я получил "no changes found" вместо "waiting for lock on repository". Я обнаружил, что каким-то образом путь по умолчанию был установлен так, чтобы указывать на один и тот же репозиторий, поэтому не слишком удивительно, что Mercurial будет путаться.

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

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

hg debuglock показать это: замок: свободный WL: (66722s)

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

Используя Win7 и TortoizeHg 4.8.7.