Mercurial застрял в ожидании блокировки
-
08-06-2019 - |
Вопрос
Получил синий экран в Windows при клонировании ртутного репозитория.
После перезагрузки я получаю это сообщение почти для всех команд 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!
Гугл не поможет.
Какие-нибудь советы?
Решение
При «ожидании блокировки репозитория» удалите файл репозитория: .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.
% 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]
После этого прерванное извлечение прошло успешно.
Блокировка была установлена более двух лет назад процессом на машине, которая больше не находится в локальной сети.Позор разработчикам hg за а) недостаточное документирование блокировок;б) не отмечать их временем для автоматического удаления, когда они устаревают.
У коллеги сегодня возникла именно такая проблема, после BSoD при попытке нажать.Он должен был:
- удалить файл
.hg/store/lock
(согласно принятый ответ) - удалить файл
.hg/store/phaseroots
(согласно этот отчет об ошибке TortoiseHG)
Затем его репо снова заработало.
РЕДАКТИРОВАТЬ: Согласно комментарию @Marmoute - при решении проблем, связанных с блокировкой, используйте hg debuglock
является более безопасной альтернативой слепому удалению .hg/store/lock
файл.
Я очень хорошо знаком с кодом блокировки Mercurial (начиная с версии 1.9.1).Совет выше хорош, но я бы добавил следующее:
- Я видел такое в реальной жизни, но редко и только на машинах с Windows.
- Удаление файлов блокировки — самое простое решение, НО вы должны убедиться, что ничто другое не имеет доступа к хранилищу.(Если блокировка представляет собой строку нулей, это почти наверняка так).
(Для любопытных:Мне пока не удалось выявить причину этой проблемы, но подозреваю, что это либо старая версия Mercurial, обращающаяся к репозиторию, либо проблема в вызове Pythonsocket.gethostname() в некоторых версиях Windows.)
У меня была такая же проблема на Win 7.Решением было удалить следующие файлы:
- .hg/store/phaseroots
- .hg/wlock
Что касается .hg/store/lock - такого файла не было.
Я не ожидаю, что это будет выигрышный ответ, но это довольно необычная ситуация.Упоминание на случай, если с этим столкнется кто-то кроме меня.
Сегодня я получил сообщение «Ожидание блокировки репозитория» по команде hg push.
Когда я убил команду Hang 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 запутался.
Если это происходит только на подключенных дисках, возможно, это ошибка. https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share.Использование пути UNC вместо буквы диска, похоже, позволяет обойти проблему.
У меня такая же проблема.Получил следующее сообщение, когда я попытался зафиксировать:ожидание блокировки рабочего каталога, принадлежащего ''
hg debuglock показал это:замок:Свободный Wcke:(66722с)
Итак, я выполнил следующую команду, и это решило проблему для меня:отладка hg -W
Использование Win7 и TortoizeHg 4.8.7.