머큐리얼이 "잠금 대기 중"으로 멈춤

수은 저장소를 복제하는 동안 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 기준). 위의 조언은 좋지만 다음과 같이 추가합니다.

1. 나는 이것을 야생에서 보았지만 드물게 Windows 시스템에서만 보았습니다.
2. 잠금 파일을 삭제하는 것이 가장 쉬운 해결 방법이지만 저장소에 액세스중인 다른 파일이 없어야합니다. (자물쇠가 0의 문자열이면 거의 확실합니다.)

(호기심 :이 문제의 원인을 아직 파악할 수 없었지만 저장소에 액세스하는 이전 버전의 Mercurial이거나 특정 버전의 Windows에서 Python의 socket.gethostname () 호출의 문제라고 생각합니다.)

Win 7에서 동일한 문제가 발생했습니다. 해결책은 다음 파일을 제거하는 것이 었습니다.

1. .hg / store / phaseroots
2. .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가 전혀 작동하지 않는다는 것에 놀랐습니다.

나는 같은 문제가 있었다. 커밋하려고 할 때 다음 메시지가 나타납니다.

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

hg debuglock 이것을 보여 주었다 :

lock:  free
wlock:  (66722s)

그래서 다음 명령을 수행하고 문제가 해결되었습니다.

hg debuglocks -W

Win7 및 TortoiseHg 사용 4.8.7.

잠긴 저장소가 원본 인 경우 수정 된 것으로 상상할 수 없습니다 경우 복제하도록 했다고 중간에서 변경하여 복제본을 망칠 수 없습니다. 자물쇠를 제거한 후에는 괜찮습니다.

새로운 복제 된 사본 (로컬 복제 인 경우)은 모든 종류의 기형 상태 일 수 있으므로 버리고 다시 시작해야합니다. (원격 복제라면 실패하고 이미 불완전한 복사본을 버렸으면 좋겠다.)

푸시하려고 할 때 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 경로를 사용하면 문제를 회피하는 것 같습니다.