Mercurial macet "menunggu kunci"

346

Punya layar blues di windows saat kloning repositori lincah.

Setelah reboot, saya sekarang mendapatkan pesan ini untuk hampir semua perintah hg:

c: \ src \> hg komit
menunggu kunci pada repositori c: \ src \ McVrsServer dipegang oleh '\ x00 \ x00 \ x00 \ x00 \ x00 \
x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 '
terganggu!

Google tidak membantu.

Ada tips?

mercurial

— jm.
sumber

3

Wow, saya juga punya bluescreen saat melakukan dan mendapatkan kesalahan yang sama. Senang saya bukan satu-satunya!

— CBarr

3

Saya mengusulkan umpan balik yang lebih baik dari pesan kesalahan di bz.selenic.com/show_bug.cgi?id=4752

— Karl Richter

489

Saat "menunggu kunci repositori", hapus file repositori: .hg/wlock(atau mungkin ada di .hg/store/lock)

Saat menghapus file kunci, Anda harus memastikan tidak ada lagi yang mengakses repositori. (Jika kuncinya adalah nol atau kosong, ini hampir pasti benar).

— jm.
sumber

103

Masalah saya tidak ada hubungannya dengan kloning atau BSOD tetapi bagi saya, saya menghapus file .hg / wlock untuk membersihkan kunci.

— frank hadder

32

hg recoverharus dijalankan setelah situasi penguncian yang rusak.

— James Broadhead

9

Terima kasih banyak - setelah menghapus .hg / wlock saya tidak tahu apa masalahnya

— Andrew Buss

34

Dalam kasus saya (TortoiseHg V2.9.2 dengan Mercurial 2.7.2), nama file adalah "wlock" bukan "lock"; dan itu ditempatkan di direktori ".hg", bukan di ".hg / store".

— Fernando

7

@Marmoute - repositori dikunci setiap kali perubahan akan dilakukan. Jika ada sesuatu yang menyebabkan proses itu gagal - yaitu, bug di Mercurial, mesin turun, dll - file kunci tetap, tidak dibersihkan. Saya percaya saran di sini untuk menghapus file kunci secara manual adalah untuk mengatasi kasus-kasus di mana repositori itu entah bagaimana ditinggalkan dalam keadaan "kotor". Menyebutnya "menghapus perlindungan lincah secara membabi buta" bukanlah karakterisasi yang adil atau akurat tentang apa yang terjadi dalam kasus-kasus ini.

— JoGusto

345

Kapan waiting for lock on working directory, hapus .hg/wlock.

— Tiago Matos
sumber

6

Inilah yang terjadi pada saya. Itu adalah symlink pada 'nix to the current server:pid. Terima kasih banyak. Kemudian saya harus lari $ hg recoveruntuk menghapus jurnal yang ada (& melakukan pesan) yang saya ctrl+cedit. Tidak yakin, tetapi Anda mungkin dapat menjalankan $ hg recovertanpa menghapus file kunci dan itu akan melakukannya untuk Anda. Layak dicoba.

— sholsinger

2

Hanya sebuah catatan untuk @sholsinger untuk mengatakan bahwa menjalankan hg pemulihan tidak berfungsi kecuali jika Anda melepas kunci terlebih dahulu. Saya mencobanya.

— Dan

1

Repositori dikunci karena suatu alasan, proses lain sedang bekerja pada repo. Anda harus menemukan proses itu dan menghentikannya alih-alih menghapus perlindungan lincah secara membuta. Hanya dengan menjatuhkan file dapat menyebabkan kerusakan repositori.

— Marmoute

@Marmoute Dalam kasus saya, saya harus menghapus kunci, karena tidak ada proses lain yang bekerja pada repo. Tapi saya setuju, ada baiknya mencari proses lain dulu

— Mi-La

Saya menerima pesan ini tiba-tiba ketika mencoba menarik, setelah menarik dan mendorong selama beberapa hari tanpa masalah. Setelah menghapus file masalah terpecahkan. File itu dari 0 KB yang berarti saya kira itu kosong. Apakah boleh menghapus file saja? Saya kira itu berguna untuk perlindungan.

— Ben Carp

47

Saya punya masalah ini tanpa file kunci yang terdeteksi. Saya menemukan solusinya di sini: http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError

Berikut ini adalah transkrip dari konsol 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]

Setelah ini tarikan yang dibatalkan berjalan dengan sukses.

Kunci telah diatur lebih dari 2 tahun yang lalu, dengan proses pada mesin yang tidak lagi di LAN. Malu pada pengembang hg untuk a) tidak mendokumentasikan kunci secara memadai; b) tidak mencatat waktu untuk dihapus secara otomatis saat basi.

— Thomas Sharpless
sumber

23

Protip: Jika wlockyang terkunci, gunakanhg debuglocks --force-wlock

— Brad Turek

5

Saya telah menggunakan kura-kura hg selama 7+ tahun. Saya tidak pernah melihat masalah sampai sekitar 3 bulan yang lalu. Saya sudah melihatnya 3 kali dalam 3 bulan terakhir. Beberapa pembaruan pasti memperburuk masalah.

— d ei

20

Rekan kerja memiliki masalah yang sama hari ini, setelah BSoD ketika mencoba untuk mendorong. Dia harus:

hapus file .hg/store/lock(sesuai jawaban yang diterima )
hapus file .hg/store/phaseroots(sesuai dengan laporan bug TortoiseHG ini )

Kemudian repo-nya bekerja lagi.

EDIT: Sesuai komentar @ Marmoute - saat menangani masalah terkait kunci, menggunakan hg debuglockadalah alternatif yang lebih aman untuk menghapus .hg/store/lockfile secara membabi buta .

— Ian Kemp
sumber

2

1) Sama sekali tidak ada alasan Anda harus menyentuh file phaseroots, itu absolutly dan tidak terkait dengan penguncian. 2) membutakan menghapus wlock adalah ide yang buruk, ada kemungkinan proses lain menggunakannya. gunakan hg debuglock untuk mencari tahu apa yang terjadi dan menghentikan proses memegang kunci

— Marmoute

3

1) Menimbang bahwa menghapusnya memperbaiki masalah, saya harus tidak setuju. 2) Tidak tahu tentang debugg hg pada saat itu (tidak dapat menemukan dokumentasi di sana juga), dan karena sistem baru saja muncul dari reboot, jelas tidak ada yang mengunci repositori - maka menghapus file kunci sesuai.

— Ian Kemp

12

Saya sangat akrab dengan kode penguncian Mercurial (pada 1.9.1). Saran di atas bagus, tetapi saya akan menambahkan bahwa:

Saya pernah melihat ini di alam liar, tetapi jarang, dan hanya pada mesin Windows.
Menghapus file kunci adalah cara termudah, TETAPI Anda harus memastikan tidak ada lagi yang mengakses repositori. (Jika kuncinya adalah string nol, ini hampir pasti benar).

(Untuk yang penasaran: Saya belum dapat mengetahui penyebab masalah ini, tetapi saya curiga itu adalah versi Mercurial lama yang mengakses repositori atau masalah pada socket Python. Gethostname () panggil versi Windows tertentu.)

— Brad O
sumber

2

FWIW itu baru saja terjadi pada saya di Ubuntu. Ini adalah pertama kalinya saya menggunakan repositori dalam beberapa minggu, jadi saya tidak ingat apa yang bisa meninggalkannya dalam keadaan itu.

— Cosmologicon

7

Saya memiliki masalah yang sama pada Win 7. Solusinya adalah menghapus file berikut:

.hg / store / phaseroots
.hg / wlock

Adapun .hg / store / lock - tidak ada file seperti itu.

— Ivan Dulov
sumber

Selamat datang di Stackoverflow. Cobalah untuk menambahkan lebih banyak konten ke pos

— NJInamdar

5

1) Sama sekali tidak ada alasan Anda harus menyentuh file phaseroots, itu absolutly dan tidak terkait dengan penguncian. 2) membutakan menghapus wlock adalah ide yang buruk, ada kemungkinan proses lain menggunakannya. gunakan hg debuglockuntuk mencari tahu apa yang terjadi dan menghentikan proses memegang kunci.

— Marmoute

6

Saya tidak berharap ini menjadi jawaban yang menang, tetapi ini adalah situasi yang cukup tidak biasa. Menyebutkan kalau-kalau ada orang selain saya yang menabraknya.

Hari ini saya mendapatkan "menunggu kunci pada repositori" pada perintah push hg.

Ketika saya membunuh perintah hung hg saya tidak bisa melihat .hg / store / lock

Ketika saya mencari .hg / store / lock ketika perintah digantung, itu ada. Tetapi lockfile dihapus ketika perintah hg terbunuh.

Ketika saya pergi ke target push, dan mengeksekusi hg pull, tidak masalah.

Akhirnya saya menyadari bahwa ID proses pada push hg adalah pesan tunggu kunci berubah setiap kali. Ternyata "hg push" menggantung menunggu kunci dipegang dengan sendirinya (atau mungkin subproses, saya tidak menyelidiki lebih lanjut).

Ternyata kedua ruang kerja, sebut saja mereka A dan B, memiliki .hg pohon yang dibagikan oleh symlink:

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

Ini BUKAN hal yang baik untuk dilakukan dengan Mercurial. Mercurial tidak memahami konsep dua ruang kerja yang berbagi repositori yang sama. Saya mengerti, bagaimanapun, bagaimana seseorang yang datang ke Mercurial dari VCS lain mungkin menginginkan ini (Perforce tidak, meskipun bukan DVCS; Bazaar DVCS dilaporkan dapat melakukannya). Saya terkejut bahwa REP-ROOT / .hg yang disinkronkan bekerja sama sekali, meskipun tampaknya kecuali untuk dorongan ini.

— Krazy Glew
sumber

Tidak melacak hg langsung masuk .hg/? Ketika Anda mengatakan bahwa repositori “bekerja”, tidakkah berjalan hg updi satu tempat membuat direktori tidak sinkron dengan yang lain — atau apakah mercurial melakukan sesuatu yang istimewa untuk mendukung hal ini?

— binki

1

Anda dapat menggunakan ekstensi berbagi (dikirimkan dengan Core Mercurial) untuk memiliki beberapa direktori kerja dari satu repositori.

— Marmoute

4

Saya memiliki masalah yang sama. Dapatkan pesan berikut ketika saya mencoba melakukan:

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

hg debuglock menunjukkan ini:

lock:  free
wlock:  (66722s)

Jadi saya melakukan perintah berikut, dan itu memperbaiki masalah bagi saya:

hg debuglocks -W

Menggunakan Win7 dan TortoiseHg 4.8.7.

— pengguna10125940
sumber

2

Jika repo yang dikunci adalah yang asli, saya tidak bisa membayangkan itu memodifikasinya untuk mengkloningnya, jadi itu hanya mencegah Anda mengubahnya di tengah dan mengacaukan klon. Itu harus baik-baik saja setelah melepas kunci.

Namun, salinan yang dikloning baru (jika itu adalah klon lokal) bisa dalam kondisi cacat apa pun, jadi Anda harus membuangnya dan memulainya dari awal. (Jika itu adalah klon jarak jauh, saya berharap itu gagal dan sudah membuang salinan yang tidak lengkap.)

— markpasc
sumber

2

Saya mengalami masalah ini pada Mac OS X 10.7.5 dan Mercurial 2.6.2 ketika mencoba untuk mendorong. Setelah memutakhirkan ke Mercurial 3.2.1, saya mendapat "tidak ada perubahan yang ditemukan" alih-alih "menunggu kunci pada repositori". Saya menemukan bahwa entah bagaimana jalur default telah ditetapkan untuk menunjuk ke repositori yang sama, jadi tidak terlalu mengejutkan bahwa Mercurial akan menjadi bingung.

— JWWalker
sumber

1

Saya menemukan bahwa entah bagaimana jalur default telah ditetapkan untuk menunjuk ke repositori yang sama . Ini. Terima kasih, Anda - Saya melalui loop untuk menyingkirkan masalah dan pathpengaturan adalah pelakunya.

— WoJ

1

Jika itu hanya terjadi pada drive yang dipetakan, itu mungkin bug https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share . Menggunakan jalur UNC alih-alih huruf drive tampaknya menghindari masalah ini.

— matt wilkie
sumber