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

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?

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).

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

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ą.

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

• usuń plik .hg/store/lock(zgodnie z zaakceptowaną odpowiedzią )
• usuń plik .hg/store/phaseroots(zgodnie z tym raportem błędu TortoiseHG )

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.

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).

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.

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.

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.

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ę.)

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.

Jeśli zdarza się to tylko na mapowanych dyskach, może to oznaczać błąd https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share . Wydaje się, że użycie ścieżki UNC zamiast litery dysku pomija problem.