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

Question

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

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

c:\src\>hg commit
waiting for lock on repository c:\src\McVrsServer held by '\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
interrupted!

Google не помогает.

Любые советы?

Answer 1

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

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

Answer 2

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

Answer 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 за то, что они не документируют блокировки должным образом; б) не ставить метки времени для автоматического удаления, когда они устаревают.

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

hg debuglock показал это: блокировка: бесплатно wlock: (66722 с)

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

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