Rtęć utknął „czekając na zamek”

346

Mam bluescreen w oknach podczas klonowania repozytorium rtęciowego.

Po ponownym uruchomieniu otrzymuję teraz ten komunikat dla prawie wszystkich poleceń hg:

c: \ src \> hg commit
oczekiwanie na blokadę w repozytorium c: \ src \ McVrsServer w posiadaniu '\ x00 \ x00 \ x00 \ x00 \ x00 \
x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 '
przerwane!

Google nie pomaga.

Jakieś wskazówki?

jm.
źródło
3
Wow, miałem także niebieski ekran podczas zatwierdzania i dostałem ten sam błąd. Cieszę się, że nie jestem jedyny!
CBarr
3
Zaproponowałem lepszą informację zwrotną na temat komunikatu o błędzie na stronie bz.selenic.com/show_bug.cgi?id=4752
Karl Richter

Odpowiedzi:

489

Gdy „czekasz na blokadę w repozytorium”, usuń plik repozytorium: .hg/wlock(lub może być w .hg/store/lock)

Podczas usuwania pliku blokady należy upewnić się, że nic innego nie ma dostępu do repozytorium. (Jeśli blokada jest ciągiem zer lub pustym, jest to prawie na pewno prawda).

jm.
źródło
103
Mój problem nie miał nic wspólnego z klonowaniem lub BSOD, ale dla mnie usunąłem plik .hg / wlock, aby wyczyścić blokadę.
Frank Hadder
32
hg recovernależy uruchomić po zepsutej sytuacji blokowania.
James Broadhead,
9
Wielkie dzięki - po usunięciu .hg / wlock nie miałem pojęcia, o co chodzi
Andrew Buss
34
W moim przypadku (TortoiseHg V2.9.2 z Mercurial 2.7.2) nazwa pliku brzmiała „wlock” zamiast „lock”; i został umieszczony w katalogu „.hg”, a nie w „.hg / store”.
Fernando
7
@Marmoute - repozytorium jest blokowane za każdym razem, gdy nastąpi zmiana. Jeśli coś spowoduje awarię tego procesu - np. Błąd w Mercurial, awaria komputera itp. - pliki blokujące pozostają, a nie są czyszczone. Uważam, że sugestie, aby ręcznie usunąć pliki blokady, dotyczą tych przypadków, w których repozytorium zostało w jakiś sposób pozostawione w stanie „nieczystym”. Nazwanie go „ślepym usuwaniem ochrony rtęciowej” nie jest uczciwą ani dokładną charakterystyką tego, co dzieje się w tych przypadkach.
JoGusto,
345

Kiedy waiting for lock on working directoryusuń .hg/wlock.

Tiago Matos
źródło
6
Tak było w moim przypadku. To było dowiązanie symboliczne do 'nix do prądu server:pid. Wielkie dzięki. Potem musiałem biec, $ hg recoverżeby wyczyścić istniejący dziennik (i komunikat zatwierdzenia), który napisałem ctrl+c. Nie jestem pewien, ale możesz być w stanie uruchomić $ hg recoverbez usuwania pliku blokady, a zrobi to za Ciebie. Warto spróbować.
sholsinger
2
Tylko uwaga dla @sholsinger, aby powiedzieć, że uruchomienie odzyskiwania hg nie działa, chyba że najpierw usuniesz blokadę. Próbowałem tego.
Dan
1
Repozytorium zostało zablokowane z jakiegoś powodu, inny proces pracuje nad repozytorium. Powinieneś znaleźć ten proces i zakończyć go zamiast ślepo usuwać ochronę rtęciową. Samo usunięcie pliku może doprowadzić do uszkodzenia repozytorium.
Marmoute,
@Marmoute W moim przypadku musiałem usunąć blokadę, ponieważ żaden inny proces nie działał na repo. Ale zgadzam się, że najpierw warto poszukać innego procesu
Mi-La
Nagle otrzymałem tę wiadomość, gdy próbowałem ciągnąć, po ciągnięciu i pchaniu przez kilka dni bez żadnych problemów. Po usunięciu pliku problem został rozwiązany. Plik miał 0 KB, co oznacza, że ​​chyba był pusty. Czy wystarczy usunąć plik? Myślę, że jest to przydatne do ochrony.
Ben Carp
47

Miałem ten problem bez wykrywalnych plików blokujących. Znalazłem rozwiązanie tutaj: http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError

Oto transkrypcja z konsoli 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]

Po tym przerwane pociągnięcie przebiegło pomyślnie.

Blokada została ustawiona ponad 2 lata temu, w procesie na maszynie, która nie jest już w sieci LAN. Szkoda deweloperom hg za a) niewystarczające dokumentowanie blokad; b) nie oznacza ich czasowo do automatycznego usuwania, gdy się zestarzeją.

Thomas Sharpless
źródło
23
Protip: Jeśli ten wlockjest zamknięty, użyjhg debuglocks --force-wlock
Brad Turek
5
Używam żółwia hg od 7+ lat. Nigdy nie widziałem problemu aż około 3 miesięcy temu. Widziałem to 3 razy w ciągu ostatnich 3 miesięcy. Niektóre aktualizacje musiały zaostrzyć problem.
d ei
20

Współpracownik miał dzisiaj dokładnie ten problem, po BSoD podczas próby pchania. Musiał:

Potem jego repo znów zadziałało.

EDYCJA: Zgodnie z komentarzem @ Marmoute - w przypadku problemów związanych z blokadą używanie hg debuglockjest bezpieczniejszą alternatywą dla ślepego usuwania .hg/store/lockpliku.

Ian Kemp
źródło
2
1) Nie ma absolutnie żadnego powodu, dla którego powinieneś dotykać pliku rootroots, jest to absolutnie niezwiązane z blokowaniem. 2) zasłonięcie usuwania wlocka to zły pomysł, prawdopodobnie używa go inny proces. użyj debuglocka hg, aby dowiedzieć się, co się dzieje, i zakończ proces z blokadą
Marmoute
3
1) Biorąc pod uwagę, że usunięcie go rozwiązało problem, musiałbym się nie zgodzić. 2) Nie wiedziałem o debugowaniu hg w tym czasie (nie mogę też znaleźć żadnej dokumentacji), a ponieważ system właśnie wyszedł z ponownego uruchomienia, oczywiście nie było blokowania repozytorium - dlatego usunięcie pliku blokady było właściwe.
Ian Kemp,
12

Bardzo dobrze znam kod blokujący Mercurial (od 1.9.1). Powyższa rada jest dobra, ale dodam, że:

  1. Widziałem to na wolności, ale rzadko i tylko na komputerach z systemem Windows.
  2. Usuwanie plików blokujących jest najłatwiejszym rozwiązaniem, ALE musisz się upewnić, że nic więcej nie ma dostępu do repozytorium. (Jeśli blokada jest ciągiem zer, prawie na pewno jest to prawda).

(Dla ciekawskich: nie udało mi się jeszcze złapać przyczyny tego problemu, ale podejrzewam, że jest to albo starsza wersja Mercurial uzyskująca dostęp do repozytorium, albo problem z wywołaniem funkcji socket.gethostname () Pythona w niektórych wersjach systemu Windows).

Brad O
źródło
2
FWIW to właśnie przydarzyło mi się na Ubuntu. Po raz pierwszy korzystałem z repozytorium od kilku tygodni, więc nie pamiętam, co mogło pozostawić go w tym stanie.
Cosmologicon
7

Miałem ten sam problem na Win 7. Rozwiązaniem było usunięcie następujących plików:

  1. .hg / store / Phaseroots
  2. .hg / wlock

Co do .hg / store / lock - nie było takiego pliku.

Ivan Dulov
źródło
Witamy w Stackoverflow. Spróbuj dodać więcej treści do postu
NJInamdar
5
1) Nie ma absolutnie żadnego powodu, dla którego powinieneś dotykać pliku rootroots, jest to absolutnie niezwiązane z blokowaniem. 2) zasłonięcie usuwania wlocka to zły pomysł, prawdopodobnie używa go inny proces. użyj, hg debuglockaby dowiedzieć się, co się dzieje, i zakończ proces przytrzymywania zamka.
Marmoute,
6

Nie oczekuję, że będzie to zwycięska odpowiedź, ale jest to dość niezwykła sytuacja. Wspominając, na wypadek, gdyby wpadł na to ktoś inny niż ja.

Dzisiaj dostałem „oczekiwanie na blokadę w repozytorium” za pomocą polecenia push hg.

Kiedy zabiłem zawieszone polecenie hg, nie widziałem .hg / store / lock

Kiedy szukałem .hg / store / lock, gdy polecenie było zawieszone, istniało. Ale plik blokujący został usunięty po zabiciu polecenia hg.

Kiedy podszedłem do celu push i wykonałem hg pull, nie ma problemu.

W końcu zdałem sobie sprawę, że identyfikator procesu na hg push to komunikat oczekiwania na blokadę zmieniał się za każdym razem. Okazuje się, że „hg push” wisiał w oczekiwaniu na blokadę utrzymywaną przez siebie (lub ewentualnie podproces, którego nie badałem dalej).

Okazuje się, że dwa obszary robocze, nazwijmy je A i B, miały drzewa .hg współdzielone przez dowiązanie symboliczne:

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

To NIE jest dobra rzecz związana z Mercurialem. Mercurial nie rozumie koncepcji dwóch obszarów roboczych współdzielących to samo repozytorium. Rozumiem jednak, jak ktoś przychodzący do Mercurial z innego VCS może tego chcieć (Perforce tak robi, chociaż nie DVCS; podobno bazar DVCS może to zrobić). Dziwię się, że w ogóle działa symbolicznie REP-ROOT / .hg, chociaż wydaje się, że wyklucza to push.

Krazy Glew
źródło
Czy hg nie śledzi dirstate .hg/? Kiedy mówisz, że repozytoria „działają”, czy nie działa hg upw jednym z nich, nie powoduje synchronizacji dirstate w drugim - czy też mercurial robi coś specjalnego, aby to wspierać?
binki,
1
Możesz użyć rozszerzenia udziału (dostarczanego z Core Mercurial), aby mieć wiele katalogów roboczych z jednego repozytorium.
Marmoute,
4

Miałem ten sam problem. Podczas próby zatwierdzenia dostałem następujący komunikat:

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

hg debuglock pokazał to:

lock:  free
wlock:  (66722s)

Zrobiłem więc następujące polecenie i to rozwiązało problem:

hg debuglocks -W

Korzystanie z Win7 i TortoiseHg 4.8.7.

użytkownik10125940
źródło
2

Jeśli zablokowane repozytorium było oryginałem, nie wyobrażam sobie, żeby było modyfikowane go, aby go sklonować, więc zapobiegało to tylko zmianie go w środku i zepsuciu klonu. Po zdjęciu blokady powinno być dobrze.

Nowa sklonowana kopia (jeśli był to klon lokalny) może być jednak w jakimkolwiek zniekształconym stanie, więc powinieneś ją wyrzucić i zacząć od nowa. (Gdyby był to zdalny klon, miałbym nadzieję, że zawiódł i już wyrzucił niekompletną kopię.)

markpasc
źródło
2

Podczas próby wypchnięcia napotkałem ten problem w systemie Mac OS X 10.7.5 i Mercurial 2.6.2. Po aktualizacji do wersji Mercurial 3.2.1 otrzymałem „brak zmian” zamiast „czekania na blokadę repozytorium”. Dowiedziałem się, że jakoś domyślna ścieżka została ustawiona tak, aby wskazywała to samo repozytorium, więc nic dziwnego, że Mercurial się pomyli.

JWWalker
źródło
1
Dowiedziałem się, że jakoś domyślna ścieżka została ustawiona tak, aby wskazywała to samo repozytorium . To. Dziękuję - przeszedłem przez pętle, aby pozbyć się problemu, a pathustawienie było winowajcą.
WoJ