Mercurial ค้างอยู่“ กำลังรอการล็อค”

346

มีหน้าจอ bluescreen ใน windows ในขณะที่ทำการโคลนคลังเก็บสินค้า

หลังจากรีบูตตอนนี้ฉันได้รับข้อความนี้สำหรับคำสั่ง hg เกือบทั้งหมด:

c: \ src \> hg กระทำ
กำลังรอการล็อกที่เก็บข้อมูล c: \ src \ McVrsServer ที่จัดขึ้นโดย '\ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \
x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00'
ขัดจังหวะ!

Google ไม่มีทางช่วย

เคล็ดลับใด ๆ

mercurial

— JM
แหล่งที่มา

3

ว้าวฉันยังมีหน้าจอ bluescreen ในขณะที่ยืนยันและได้รับข้อผิดพลาดเดียวกัน ดีใจที่ฉันไม่ใช่คนเดียว!

— CBarr

3

ฉันเสนอข้อเสนอแนะที่ดีขึ้นของข้อผิดพลาดที่bz.selenic.com/show_bug.cgi?id=4752

— Karl Richter

489

เมื่อ "กำลังรอการล็อกที่เก็บ" ลบไฟล์ที่เก็บ: .hg/wlock(หรืออาจอยู่ใน.hg/store/lock)

เมื่อลบไฟล์ล็อคคุณต้องแน่ใจว่าไม่มีสิ่งใดที่เข้าถึงที่เก็บข้อมูล (ถ้าล็อคเป็นสตริงศูนย์หรือว่างนี่เป็นเรื่องจริงเกือบแน่นอน)

— JM
แหล่งที่มา

103

ปัญหาของฉันไม่เกี่ยวกับการโคลนหรือ BSOD แต่สำหรับฉันฉันลบไฟล์. hg / wlock เพื่อล้างการล็อค

— ตรงไปตรงมา hadder

32

hg recoverควรจะรันหลังจากสถานการณ์การล็อคผิดพลาด

— James Broadhead

9

ขอบคุณมาก - หลังจากลบ. hg / wlock ฉันไม่ทราบว่าปัญหาคืออะไร

— Andrew Buss

34

ในกรณีของฉัน (TortoiseHg V2.9.2 กับ Mercurial 2.7.2) ชื่อไฟล์คือ "wlock" แทนที่จะเป็น "lock"; และวางไว้ในไดเรกทอรี ".hg" ไม่ใช่ใน ".hg / store"

— เฟอร์นันโด

7

@Marmoute - พื้นที่เก็บข้อมูลจะถูกล็อคทุกครั้งที่มีการเปลี่ยนแปลง หากมีสิ่งใดที่ทำให้กระบวนการนั้นล้มเหลว - เช่นมีข้อบกพร่องใน Mercurial, เครื่องหยุดทำงาน, ฯลฯ - ไฟล์ล็อคยังคงอยู่, ไม่ได้ล้างออก ฉันเชื่อว่าคำแนะนำที่นี่เพื่อลบไฟล์ล็อคด้วยตนเองคือการจัดการกับกรณีที่พื้นที่เก็บข้อมูลถูกทิ้งให้อยู่ในสถานะ "สกปรก" การเรียกมันว่า "การเอาการป้องกันแบบปรอทออกอย่างสุ่มสี่สุ่มห้า" ไม่ใช่ลักษณะที่ยุติธรรมและไม่ถูกต้องของสิ่งที่เกิดขึ้นในกรณีนี้

— JoGusto

345

เมื่อลบwaiting for lock on working directory.hg/wlock

— Tiago Matos
แหล่งที่มา

6

นี่เป็นกรณีสำหรับฉัน มันเป็น symlink ที่ server:pid'ระวังถึงปัจจุบัน ขอบคุณมัด จากนั้นฉันต้องวิ่ง$ hg recoverออกไปเพื่อล้างบันทึกประจำวันที่มีอยู่ (& ส่งข้อความ) ที่ฉันctrl+cต้องการ ไม่แน่ใจ แต่คุณสามารถใช้งานได้$ hg recoverโดยไม่ต้องลบไฟล์ล็อคและมันจะทำเพื่อคุณ คุ้มค่ากับการยิงฉันคิดว่า

— sholsinger

2

เพียงบันทึกย่อสำหรับ @sholsinger เพื่อบอกว่าการเรียกใช้การกู้คืน hg ไม่ทำงานจนกว่าคุณจะลบล็อคออกก่อน ฉันลองแล้ว

— Dan

1

ที่เก็บถูกล็อคด้วยเหตุผลกระบวนการอื่นกำลังทำงานกับ repo คุณควรหากระบวนการนั้นและยุติมันแทนการเอาการป้องกันแบบปรอทออกอย่างสุ่ม ๆ เพียงแค่วางไฟล์สามารถนำไปสู่ความเสียหายของที่เก็บ

— Marmoute

@Marmoute ในกรณีของฉันฉันต้องลบล็อคเพราะไม่มีกระบวนการอื่นทำงานใน repo แต่ฉันเห็นด้วยมันคุ้มค่าที่จะมองหากระบวนการอื่นก่อน

— Mi-La

ฉันได้รับข้อความนี้ทันทีที่พยายามดึงหลังจากดึงและผลักดันสองสามวันโดยไม่มีปัญหา หลังจากลบไฟล์ปัญหาได้รับการแก้ไข ไฟล์นี้มีขนาด 0 KB ซึ่งหมายความว่าฉันคิดว่ามันว่างเปล่า มันเป็นการง่ายที่จะลบไฟล์? ฉันเดาว่ามันมีประโยชน์สำหรับการป้องกัน

— เบ็นปลาคาร์พ

47

ฉันมีปัญหานี้โดยไม่มีไฟล์ล็อคที่ตรวจพบได้ ฉันพบวิธีแก้ปัญหาที่นี่: 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]

หลังจากนี้การยกเลิกการดึงก็จะสำเร็จ

ล็อคได้รับการตั้งค่ามากกว่า 2 ปีที่ผ่านมาโดยกระบวนการในเครื่องที่ไม่ได้อยู่บน LAN อีกต่อไป ความอัปยศต่อนักพัฒนา hg สำหรับ a) ไม่บันทึกการล็อคอย่างเพียงพอ; b) ไม่ประทับเวลาพวกเขาสำหรับการลบอัตโนมัติเมื่อพวกเขาค้าง

— โทมัสชาร์ป
แหล่งที่มา

23

Protip: ถ้าwlockล็อคไว้ให้ใช้hg debuglocks --force-wlock

— Brad Turek

5

ฉันใช้เต่ามานานกว่า 7 ปีแล้ว ฉันไม่เคยเห็นปัญหาจนกระทั่งประมาณ 3 เดือนที่แล้ว ฉันเคยเห็น 3 ครั้งในช่วง 3 เดือนที่ผ่านมา การอัปเดตบางอย่างต้องทำให้ปัญหารุนแรงขึ้น

— d EI

20

ผู้ร่วมงานมีปัญหาตรงนี้ในวันนี้หลังจาก BSoD ขณะพยายามผลักดัน เขาต้อง:

ลบไฟล์.hg/store/lock(ตามคำตอบที่ยอมรับ )
ลบไฟล์.hg/store/phaseroots(ตามรายงานข้อผิดพลาด TortoiseHG นี้ )

จากนั้น repo ของเขาก็ทำงานอีกครั้ง

แก้ไข:ตามความเห็นของ @ Marmoute - เมื่อจัดการกับปัญหาเกี่ยวกับล็อคการใช้hg debuglockเป็นทางเลือกที่ปลอดภัยกว่าในการลบ.hg/store/lockไฟล์แบบสุ่ม

— เอียนเคมพ์
แหล่งที่มา

2

1) ไม่มีเหตุผลใดที่คุณควรแตะที่ไฟล์ phaseroots โดยไม่เกี่ยวข้องกับการล็อค 2) การลบม่านตาปลาเป็นการลบความคิดที่ไม่ดีมีแนวโน้มว่าจะมีกระบวนการอื่นใช้ ใช้ debuglock hg เพื่อค้นหาว่าเกิดอะไรขึ้นและยุติกระบวนการที่ถือกุญแจไว้

— Marmoute

3

1) เมื่อพิจารณาว่าการลบการแก้ไขปัญหาฉันต้องไม่เห็นด้วย 2) ไม่ทราบเกี่ยวกับ debuglock hg ในเวลานั้น (ไม่พบเอกสารใด ๆ ในนั้น) และเนื่องจากระบบเพิ่งมาจากการรีบูตเครื่องจึงไม่มีอะไรล็อคที่เก็บ - ดังนั้นการลบไฟล์ล็อคจึงเหมาะสม

— Ian Kemp

12

ฉันคุ้นเคยกับรหัสล็อคของ Mercurial (เหมือน 1.9.1) คำแนะนำข้างต้นเป็นสิ่งที่ดี แต่ฉันต้องการเพิ่มว่า:

ฉันเคยเห็นสิ่งนี้ในป่า แต่ไม่ค่อยและเฉพาะในเครื่อง Windows
การลบไฟล์ล็อคเป็นการแก้ไขที่ง่ายที่สุด แต่คุณต้องแน่ใจว่าไม่มีสิ่งใดที่เข้าถึงที่เก็บข้อมูล (หากล็อคเป็นสตริงศูนย์นี่จะเป็นจริงเกือบแน่นอน)

(สำหรับคนที่อยากรู้อยากเห็น: ฉันยังไม่สามารถหาสาเหตุของปัญหานี้ได้ แต่สงสัยว่ามันเป็น Mercurial รุ่นเก่าที่เข้าถึงที่เก็บหรือปัญหาในการเรียกใช้ socket.ethostname ของ Python () บน Windows บางรุ่น)

— แบรดโอ
แหล่งที่มา

2

FWIW มันเกิดขึ้นกับฉันบน Ubuntu นี่เป็นครั้งแรกที่ฉันใช้ที่เก็บข้อมูลในอีกหลายสัปดาห์ดังนั้นฉันจำไม่ได้ว่ามีอะไรเหลืออยู่ในสถานะนั้น

— Cosmologicon

7

ฉันมีปัญหาเดียวกันกับ Win 7 วิธีแก้ไขคือลบไฟล์ต่อไปนี้:

.hg / ร้าน / phaseroots
.hg / wlock

สำหรับ. hg / store / lock - ไม่มีไฟล์ดังกล่าว

— Ivan Dulov
แหล่งที่มา

ยินดีต้อนรับสู่ Stackoverflow พยายามที่จะเพิ่มเนื้อหาเพิ่มเติมในการโพสต์

— NJInamdar

5

1) ไม่มีเหตุผลใดที่คุณควรแตะที่ไฟล์ phaseroots โดยไม่เกี่ยวข้องกับการล็อค 2) การลบม่านตาปลาเป็นการลบความคิดที่ไม่ดีมีแนวโน้มว่าจะมีกระบวนการอื่นใช้ ใช้hg debuglockเพื่อหาว่ามันเกิดอะไรขึ้นและยุติกระบวนการในการล็อค

— Marmoute

6

ฉันไม่คาดหวังว่านี่จะเป็นคำตอบที่ชนะ แต่เป็นสถานการณ์ที่ผิดปกติ กล่าวถึงในกรณีที่มีคนอื่นที่ไม่ใช่ฉันวิ่งเข้ามา

วันนี้ฉันได้รับข้อความ "กำลังรอการล็อกที่เก็บ" บนคำสั่ง hg push

เมื่อฉันฆ่าคำสั่ง Hung hg ฉันไม่เห็น. hg / store / lock

เมื่อฉันค้นหา. hg / store / lock ในขณะที่คำสั่งหยุดทำงานจะมีอยู่ แต่ lockfile ถูกลบเมื่อคำสั่ง hg ถูกฆ่า

เมื่อฉันไปที่เป้าหมายของการผลักดันและดำเนินการดึง hg ไม่มีปัญหา

ในที่สุดฉันก็รู้ว่า ID กระบวนการในการกด hg คือข้อความรอการล็อคถูกเปลี่ยนทุกครั้ง ปรากฎว่า "hg push" กำลังรอการล็อคที่จัดขึ้นเอง (หรืออาจเป็น subprocess ฉันไม่ได้ตรวจสอบเพิ่มเติม)

ปรากฎว่าทั้งสองพื้นที่ทำงานลองเรียกพวกเขาว่า A และ B มีต้นไม้. hg ที่ใช้ร่วมกันโดย symlink:

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

นี่ไม่ใช่สิ่งที่ดีที่จะทำกับ Mercurial Mercurial ไม่เข้าใจแนวคิดของพื้นที่ทำงานสองแห่งที่ใช้พื้นที่เก็บข้อมูลร่วมกันร่วมกัน อย่างไรก็ตามฉันเข้าใจว่ามีใครบางคนที่มา Mercurial จาก VCS อื่นอาจต้องการสิ่งนี้ (Perforce ทำได้แม้ว่าจะไม่ใช่ DVCS แต่รายงาน Bazaar DVCS สามารถทำได้) ฉันรู้สึกประหลาดใจที่ REP-ROOT / .hg ทำงานร่วมกันได้แม้ว่ามันจะดูเหมือนว่ายกเว้น

— Krazy Glew
แหล่งที่มา

ไม่ hg ติดตาม dirstate ใน.hg/? เมื่อคุณพูดว่าที่เก็บข้อมูล“ ทำงาน” ไม่ทำงานhg upในที่ใดที่หนึ่งทำให้ความกระหายในการซิงค์ไม่ตรงกัน - หรือ Mercurial ทำอะไรพิเศษเพื่อสนับสนุนสิ่งนี้?

— binki

1

คุณสามารถใช้ส่วนขยายการแชร์ (จัดส่งพร้อมกับ Core Mercurial) เพื่อให้มีไดเรกทอรีทำงานหลายรายการจากที่เก็บเดียว

— Marmoute

4

ผมมีปัญหาเหมือนกัน. มีข้อความต่อไปนี้เมื่อฉันพยายามส่ง:

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

hg debuglock แสดงสิ่งนี้:

lock:  free
wlock:  (66722s)

ดังนั้นฉันจึงทำตามคำสั่งและแก้ไขปัญหาให้ฉัน:

hg debuglocks -W

ใช้ Win7 และ TortoiseHg 4.8.7

— user10125940
แหล่งที่มา

2

หาก repo ที่ล็อคไว้เป็นต้นฉบับฉันไม่สามารถจินตนาการได้ว่ามันได้ทำการดัดแปลงเพื่อโคลนมันดังนั้นมันจึงป้องกันคุณไม่ให้เปลี่ยนจากตรงกลางและทำให้โคลนเลอะเทอะ มันควรจะดีหลังจากถอดล็อค

สำเนาโคลนใหม่ (ถ้าเป็นโคลนในเครื่อง) อาจอยู่ในสถานะที่ผิดรูปแบบใด ๆ ดังนั้นคุณควรทิ้งมันและเริ่มต้นใหม่ (หากเป็นโคลนระยะไกลฉันหวังว่าจะล้มเหลวและส่งสำเนาที่ไม่สมบูรณ์ออกไปแล้ว)

— markpasc
แหล่งที่มา

2

ฉันพบปัญหานี้ใน Mac OS X 10.7.5 และ Mercurial 2.6.2 เมื่อพยายามดัน หลังจากอัปเกรดเป็น Mercurial 3.2.1 ฉันได้รับ "ไม่พบการเปลี่ยนแปลง" แทนที่จะเป็น "รอการล็อกที่เก็บ" ฉันพบว่าเส้นทางเริ่มต้นถูกกำหนดให้ชี้ไปที่ที่เก็บเดียวกันดังนั้นจึงไม่น่าแปลกใจที่ Mercurial จะสับสน

— JWWalker
แหล่งที่มา

1

ผมพบว่าอย่างใดเส้นทางเริ่มต้นมีอากาศชุดที่จะชี้ไปที่พื้นที่เก็บข้อมูลเดียวกัน นี้. ขอบคุณคุณ - ฉันผ่านการวนซ้ำเพื่อกำจัดปัญหาและการpathตั้งค่าเป็นผู้ร้าย

— WoJ

1

ถ้ามันจะเกิดขึ้นในไดรฟ์ที่แมปก็อาจจะมีข้อผิดพลาดhttps://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share การใช้เส้นทาง UNC แทนอักษรระบุไดรฟ์ดูเหมือนจะเลี่ยงไม่ให้เกิดปัญหา

— แมตต์วิลคี
แหล่งที่มา