Mercurial عالق "في انتظار القفل"

Question

حصلت على شاشة زرقاء في النوافذ أثناء استنساخ مستودع زئبقي.

بعد إعادة التشغيل، أتلقى الآن هذه الرسالة لجميع أوامر hg تقريبًا:

c:\src\>hg commit
waiting for lock on repository c:\src\McVrsServer held by '\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
interrupted!

جوجل ليست مساعدة.

أي نصائح؟

Answer 1

عند "انتظار قفل المستودع"، احذف ملف المستودع: .hg/wlock (أو قد يكون في .hg/store/lock)

عند حذف ملف القفل، يجب عليك التأكد من عدم وصول أي شيء آخر إلى المستودع.(إذا كان القفل عبارة عن سلسلة من الأصفار أو فارغة، فمن المؤكد تقريبًا أن هذا صحيح).

Answer 2

متى waiting for lock on working directory, ، يمسح .hg/wlock.

Answer 3

لقد واجهت هذه المشكلة مع عدم وجود ملفات قفل يمكن اكتشافها.لقد وجدت الحل هنا: 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).عار على مطوري hg بسبب أ) عدم توثيق الأقفال بشكل كافٍ؛ب) عدم وضع طابع زمني عليها لإزالتها تلقائيًا عندما تصبح قديمة.

Answer 4

واجه زميل العمل هذه المشكلة بالضبط اليوم، بعد تعرضه لحادث الموت الزرقاء أثناء محاولته الدفع.كان عليه أن:

• احذف الملف .hg/store/lock (حسب الجواب المقبول)
• احذف الملف .hg/store/phaseroots (حسب تقرير خطأ TortoiseHG هذا)

ثم عمل الريبو الخاص به مرة أخرى.

يحرر: وفقًا لتعليق @Marmoute - عند التعامل مع المشكلات المتعلقة بالقفل، استخدم hg debuglock يعد بديلاً أكثر أمانًا للحذف الأعمى لملفات .hg/store/lock ملف.

Answer 5

أنا على دراية برمز قفل Mercurial (اعتبارًا من 1.9.1).النصيحة المذكورة أعلاه جيدة، ولكن أود أن أضيف ما يلي:

1. لقد رأيت هذا في الواقع، ولكن نادرًا، وعلى أجهزة Windows فقط.
2. يعد حذف ملفات القفل هو الحل الأسهل، ولكن عليك التأكد من عدم وصول أي شيء آخر إلى المستودع.(إذا كان القفل عبارة عن سلسلة من الأصفار، فمن المؤكد تقريبًا أن هذا صحيح).

(للفضوليين:لم أتمكن بعد من التعرف على سبب هذه المشكلة، ولكني أشك في أنها إما نسخة قديمة من Mercurial تصل إلى المستودع أو مشكلة في استدعاء Python's المقبس.gethostname() على إصدارات معينة من Windows.)

Answer 6

لقد واجهت نفس المشكلة في Win 7.الحل كان بحذف الملفات التالية:

1. .hg/store/phaseroots
2. .hg/ولوك

أما بالنسبة لـ .hg/store/lock - فلا يوجد مثل هذا الملف.

Answer 7

لا أتوقع أن تكون هذه إجابة رابحة، لكنه موقف غير عادي إلى حد ما.بالذكر في حالة وقوع شخص آخر غيري في ذلك.

لقد حصلت اليوم على "انتظار القفل في المستودع" على أمر دفع hg.

عندما قمت بقتل الأمر hanging hg لم أتمكن من رؤية .hg/store/lock

عندما بحثت عن .hg/store/lock أثناء تعليق الأمر، كان موجودًا.ولكن تم حذف ملف القفل عندما تم قتل الأمر hg.

عندما ذهبت إلى هدف الدفع، وقمت بسحب الزئبق، لم تكن هناك مشكلة.

أدركت في النهاية أن معرف العملية الموجود على hg Push كان عبارة عن رسالة انتظار القفل تتغير في كل مرة.اتضح أن "دفعة hg" كانت معلقة في انتظار القفل الذي تم تثبيته بمفرده (أو ربما عملية فرعية، لم أقم بإجراء مزيد من التحقيق).

لقد اتضح أن مساحتي العمل، لنسميهما A وB، كانتا تحتويان على أشجار .hg مشتركة بواسطة رابط رمزي:

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

هذا ليس بالأمر الجيد مع Mercurial.لا يفهم Mercurial مفهوم تقاسم مساحتي عمل في نفس المستودع.ومع ذلك، فأنا أفهم كيف قد يرغب شخص قادم إلى Mercurial من VCS آخر في ذلك (يفعل ذلك بالضرورة، على الرغم من أنه ليس DVCS؛يقال إن Bazaar DVCS يمكنه القيام بذلك).أنا مندهش من أن الارتباط الرمزي REP-ROOT/.hg يعمل على الإطلاق، على الرغم من أنه يبدو أنه باستثناء هذا الدفع.

Answer 8

إذا كان الريبو المقفل هو الأصل، فلا أستطيع أن أتخيل أنه كان كذلك تعديل لاستنساخه، لذلك كان يمنعك فقط من تغييره في المنتصف وإفساد النسخ.يجب أن يكون جيدًا بعد إزالة القفل.

يمكن أن تكون النسخة المستنسخة الجديدة (إذا كانت نسخة محلية) في أي نوع من الحالة المشوهة، لذا يجب عليك التخلص منها والبدء من جديد.(إذا كانت نسخة عن بعد، أتمنى أن تكون قد فشلت وتخلصت بالفعل من النسخة غير المكتملة.)

Answer 9

لقد واجهت هذه المشكلة في نظام التشغيل Mac OS X 10.7.5 وMercurial 2.6.2 عند محاولة الدفع.بعد الترقية إلى Mercurial 3.2.1، ظهرت لي رسالة "لم يتم العثور على أي تغييرات" بدلاً من "انتظار قفل المستودع".لقد اكتشفت أنه بطريقة ما تم ضبط المسار الافتراضي للإشارة إلى نفس المستودع، لذلك ليس من المستغرب أن يتم الخلط بين Mercurial.

Answer 10

إذا حدث ذلك فقط على محركات الأقراص المعينة، فقد يكون هناك خطأ https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share.يبدو أن استخدام مسار UNC بدلاً من حرف محرك الأقراص يتجنب المشكلة.

Answer 11

كان لي نفس المشكلة.تلقيت الرسالة التالية عندما حاولت الالتزام:في انتظار القفل على دليل العمل الذي تم الاحتفاظ به بواسطة ''

أظهر hg debuglock هذا:قفل:Wlock المجاني:(66722 ثانية)

لذلك قمت بتنفيذ الأمر التالي، وهذا حل المشكلة بالنسبة لي:زئبق debuglocks -W

باستخدام Win7 وTortoizeHg 4.8.7.