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




meaning nike (9)

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

حصلت على bluescreen في ويندوز في حين استنساخ مستودع الزئبقي.

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

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!

جوجل لا يساعد.

أي نصائح؟


كان لي نفس المشكلة في فوز 7. وكان الحل لإزالة الملفات التالية:

  1. .hg / مخزن / phaseroots
  2. .hg / wlock

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


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

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

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


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

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


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

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


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

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

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

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

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

في النهاية ، أدركت أن معرّف العملية على دفع الزئبق كان رسالة انتظار القفل يتغير في كل مرة. اتضح أن "hg push" كان معلقًا في انتظار قفل تم الاحتفاظ به بنفسه (أو ربما عملية فرعية ، ولم أقم بالتحقق أكثر).

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

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

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


كان Coworker هذه المشكلة بالضبط اليوم ، بعد BSoD أثناء محاولة دفع. كان عليه أن:

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

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


عند waiting for lock on working directory ، قم بحذف .hg/wlock .


الطريقة الصحيحة لتكرار git reset --soft HEAD^ (التراجع عن الالتزام الحالي مع الاحتفاظ بالتغييرات في نسخة العمل) هي:

hg strip --keep -r .

-1 لن يعمل إلا إذا كان الالتزام الذي تريد تجريده هو الالتزام الأخير الذي أدخل إلى مستودع التخزين. . يشير إلى الالتزام الذي تم سحبه حاليًا ، وهو أقرب ما يعادل Mercurial إلى Git's HEAD .

لاحظ أنه إذا . لديه أحفاد ، وسوف تحصل على تجريده بعيدا جدا. إذا كنت ترغب في الحفاظ على الالتزام ، فيمكنك بدلاً من ذلك:

hg update .^
hg revert --all -r <commit id>

سيؤدي هذا إلى تحديث الوالد الخاص بالالتزام ثم استبدال الملفات الموجودة في نسخة العمل بالإصدارات الموجودة في ذلك الالتزام.







mercurial