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

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

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

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

15.08.2008 23:01:16
Вау, у меня также был синий экран во время совершения, и я получил ту же ошибку. Рад, что я не единственный!
CBarr 25.06.2013 15:05:05
Я предложил более качественную обратную связь с сообщением об ошибке на сайте bz.selenic.com/show_bug.cgi?id=4752
Karl Richter 12.07.2015 09:47:45
11 ОТВЕТОВ
РЕШЕНИЕ

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

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

487
23.05.2019 14:43:33
Моя проблема не имела ничего общего с клонированием или BSOD, но я удалил файл .hg / wlock, чтобы снять блокировку.
frank hadder 28.02.2010 07:59:35
hg recoverдолжен быть запущен после сломанной ситуации блокировки.
James Broadhead 8.12.2011 16:49:29
Большое спасибо - после удаления .hg / wlock я понятия не имел, в чем проблема
Andrew Buss 1.10.2012 01:35:19
В моем случае (TortoiseHg V2.9.2 с Mercurial 2.7.2) имя файла было «wlock» вместо «lock»; и он был помещен в каталог ".hg", а не в ".hg / store".
Fernando 24.04.2015 19:41:27
@Marmoute - хранилище блокируется всякий раз, когда будет произведено изменение. Если что-то приводит к сбою этого процесса - например, ошибка в Mercurial, сбой машины и т. Д. - файлы блокировки остаются, а не очищаются. Я полагаю, что предложения по удалению файлов блокировки вручную относятся к тем случаям, когда хранилище каким-то образом оставалось в «нечистом» состоянии. Назвать это «слепым снятием меркуриальной защиты» не является ни справедливой, ни точной характеристикой того, что происходит в этих случаях.
JoGusto 12.08.2016 15:14:13

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

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

2
16.08.2008 20:54:27

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

345
12.07.2015 10:17:00
Это был случай для меня. Это была символическая ссылка 'nix на текущий server:pid. Огромное спасибо. Затем мне пришлось бежать, $ hg recoverчтобы очистить существующий журнал (и сообщение коммита), который я ctrl+cредактировал. Не уверен, но вы можете запустить $ hg recoverбез удаления файла блокировки, и он сделает это за вас. Полагаю, стоит попробовать.
sholsinger 26.04.2011 00:43:13
Просто замечание для @sholsinger о том, что запуск hg recovery не сработает, если вы сначала не удалите блокировку. Я попробовал это.
Dan 5.06.2013 18:33:56
Репозиторий заблокирован по причине, другой процесс работает над репо. Вы должны найти этот процесс и завершить его вместо того, чтобы слепо снимать ртутную защиту. Простое удаление файла может привести к повреждению хранилища.
Marmoute 25.06.2015 00:43:47
@ Marmoute В моем случае мне пришлось снять блокировку, потому что никакой другой процесс не работал на репо. Но я согласен, стоит сначала поискать другой процесс
Mi-La 26.04.2017 17:54:01
Я получил это сообщение внезапно, когда пытался потянуть, после того, как потянул и толкнул в течение нескольких дней без проблем. После удаления файла проблема была решена. Файл был размером 0 КБ, что означает, что он был пуст. Можно ли просто удалить файл? Я думаю, это полезно для защиты.
Ben Carp 15.01.2018 10:18:18

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

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

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

12
2.11.2011 13:36:33
FWIW это только что случилось со мной на Ubuntu. Я впервые использовал хранилище за несколько недель, поэтому я не помню, что могло бы оставить его в таком состоянии.
Cosmologicon 18.10.2014 14:29:27

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

1
12.07.2012 05:20:48

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

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

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

20
23.05.2017 12:34:44
1) Абсолютно нет причин, по которым вы должны обращаться к файлу Pharoroots, он абсолютно не связан с блокировкой. 2) Слепое удаление часов - плохая идея, скорее всего, другой процесс использует его. используйте hg debuglock, чтобы выяснить, что происходит, и завершите процесс, удерживающий блокировку
Marmoute 25.06.2015 00:45:09
1) Учитывая, что устранение проблемы решило проблему, я бы не согласился. 2) В то время не знал о hg debuglock (также не могу найти никакой документации по нему), и поскольку система только что вышла из перезагрузки, очевидно, что ничего не блокировало репозиторий - следовательно, удаление файла блокировки было уместно.
Ian Kemp 25.06.2015 07:30:19

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

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

6
1.08.2014 22:22:55
Hg не отслеживает dirstate .hg/? Когда вы говорите, что репозитории «работают», не работает ли hg upв одном из них синхронизация dirstate в другом - или mercurial делает что-то особенное для поддержки этого?
binki 6.03.2015 16:27:34
Вы можете использовать расширение общего ресурса (поставляется с Core Mercurial), чтобы иметь несколько рабочих каталогов из одного репозитория.
Marmoute 25.06.2015 00:47:31

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

2
24.11.2014 18:10:12
Я обнаружил, что каким-то образом заданный по умолчанию путь указывает на тот же репозиторий . Это. Спасибо, вы - я прошел через петли, чтобы избавиться от проблемы, и pathнастройка была виновником.
WoJ 2.02.2016 08:40:27

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

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

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

7
24.11.2016 16:50:29
Добро пожаловать в Stackoverflow. Попробуйте добавить больше контента к посту
NJInamdar 12.03.2015 09:33:42
1) Абсолютно нет причин, по которым вы должны обращаться к файлу Pharoroots, он абсолютно не связан с блокировкой. 2) Слепое удаление часов - плохая идея, скорее всего, другой процесс использует его. используйте, hg debuglockчтобы выяснить, что происходит, и завершите процесс, удерживающий блокировку.
Marmoute 25.06.2015 00:41:48

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

46
8.01.2017 03:43:24
Подсказка: если wlockтот заперт, используйтеhg debuglocks --force-wlock
Brad Turek 18.09.2017 16:32:52
Я использовал черепаху HG в течение 7 лет. Я никогда не видел проблемы, пока около 3 месяцев назад. Я видел это 3 раза за последние 3 месяца. Некоторое обновление должно усугубить проблему.
d ei 20.02.2018 00:49:19

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

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

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

lock:  free
wlock:  (66722s)

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

hg debuglocks -W

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

4
20.12.2019 10:43:05