수은 저장소를 복제하는 동안 Windows에 블루 스크린이 표시됩니다.
재부팅 후, 거의 모든 hg 명령에 대해이 메시지가 나타납니다.
c : \ src \> hg 커밋 '\ x00 \ x00 \ x00 \ x00 \ x00 \이 (가) 보유한 저장소 c : \ src \ McVrsServer에서 잠금 대기 중 x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 ' 중단!
Google은 도움이되지 않습니다.
팁이 있습니까?
답변
“저장소 잠금 대기 중”일 때 저장소 파일을 삭제하십시오 .hg/wlock(또는 파일 이있을 수 있음 .hg/store/lock
잠금 파일을 삭제할 때 저장소에 액세스중인 다른 것이 없어야합니다. (자물쇠가 0의 문자열이거나 공백이면, 이것은 거의 사실입니다.)
답변
일 때 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]
이 후 중단 된 풀이 성공적으로 실행되었습니다.
더 이상 LAN에없는 시스템의 프로세스에 의해 잠금이 2 년 전에 설정되었습니다. a) 잠금 장치를 적절하게 문서화하지 않음; b) 시간이 지나면 자동 제거를 위해 타임 스탬프를 작성하지 않습니다.
답변
동료는 푸시하려고하는 동안 BSoD 후에 오늘이 정확한 문제를 겪었습니다. 그는해야했다 :
- 파일을 삭제
.hg/store/lock(당 허용 대답 ) - 파일을 삭제하십시오
.hg/store/phaseroots( 이 TortoiseHG 버그 보고서에 따라 )
그런 다음 그의 repo는 다시 일했습니다.
편집 : @ Marmoute의 의견에 따라 잠금 관련 문제를 처리 할 때 hg debuglock맹목적으로 .hg/store/lock파일을 삭제하는 것보다 안전 합니다.
답변
Mercurial의 잠금 코드에 매우 익숙합니다 (1.9.1 기준). 위의 조언은 좋지만 다음과 같이 추가합니다.
- 나는 이것을 야생에서 보았지만 드물게 Windows 시스템에서만 보았습니다.
- 잠금 파일을 삭제하는 것이 가장 쉬운 해결 방법이지만 저장소에 액세스중인 다른 파일이 없어야합니다. (자물쇠가 0의 문자열이면 거의 확실합니다.)
(호기심 :이 문제의 원인을 아직 파악할 수 없었지만 저장소에 액세스하는 이전 버전의 Mercurial이거나 특정 버전의 Windows에서 Python의 socket.gethostname () 호출의 문제라고 생각합니다.)
답변
Win 7에서 동일한 문제가 발생했습니다. 해결책은 다음 파일을 제거하는 것이 었습니다.
- .hg / store / phaseroots
- .hg / wlock
.hg / store / lock에 관해서는 그러한 파일이 없었습니다.
답변
나는 이것이 답이 될 것으로 기대하지는 않지만 상당히 특이한 상황입니다. 내가 아닌 다른 사람이 부딪 칠 경우를 언급하십시오.
오늘 저는 hg push 명령으로 “저장소 잠금 대기 중”을 받았습니다.
hung hg 명령을 죽였을 때 .hg / store / lock이 보이지 않습니다.
명령이 중단 된 동안 .hg / store / lock을 찾을 때 존재했습니다. 그러나 hg 명령이 종료되면 잠금 파일이 삭제되었습니다.
내가 푸시 대상으로 가서 hg pull을 실행했을 때 아무런 문제가 없습니다.
결국 hg 푸시의 프로세스 ID는 잠금 대기 메시지가 매번 변경된다는 것을 깨달았습니다. “hg push”가 자체적으로 보유한 잠금을 기다리는 중입니다 (또는 하위 프로세스 일 수도 있습니다. 더 이상 조사하지 않았습니다).
A와 B라고 부르는 두 개의 작업 공간은 symlink가 공유하는 .hg 트리를 가지고 있음이 밝혀졌습니다.
A/.hg --symlinked-to--> B/.hg
Mercurial과는 관련이 없습니다. Mercurial은 동일한 저장소를 공유하는 두 작업 공간의 개념을 이해하지 못합니다. 그러나 다른 VCS에서 Mercurial로 오는 누군가가 이것을 원할 수도 있음을 이해합니다 (DVCS는 아니지만 Perforce는 그렇게합니다. Bazaar DVCS는 그렇게 할 수 있습니다). 이 푸시를 제외하고는 symlinked REP-ROOT / .hg가 전혀 작동하지 않는다는 것에 놀랐습니다.
