Mercurial depo bozulması

14

Bu biraz bu soru ile ilgili ama farklı bir soru.

SSH ve mercurial-server üzerinden kullanıcılara sunulan merkezi bir Hg depomuz var . Bağlanan çok sayıda Mac, Linux ve Windows istemcimiz var.

Windows kullanıcılarından birinin deposunu bozduğu, daha sonra onu bozan merkezi olana geri ittiği iki kez oldu. Merkezi depoyu bozacaksa bir işlemin kabul edilmesini önlemek için merkezi depoya gelen bir kanca komut dosyası yazmak istiyorum.

Ne yazık ki Mercurial hakkında böyle bir senaryo yazacak kadar bilgim yok. Başkasının buna rastlama ihtimali var mı? Şahsen hg'nin bunu neden varsayılan olarak yapmadığından emin değilim.

mercurial corruption

— bobinabottle
kaynak

Burada bir çözüm buldum: tüm istemcilerde yapılması gereken davidherron.com/blog/topics/… . Ama merkezi repo kendisi için yapılabilecek daha iyi bir çözüm varsa, bu daha iyi olurdu.

— bobinabottle

Lütfen bize daha fazla ayrıntı verin: Sunucuda ve istemcilerin her birinde hangi Mercurial sürümünü kullanıyorsunuz?

— Martin Geisler

2

Ayrıca, bunu yeniden üretebilirseniz bizim için (Mercurial geliştiricileri) son derece yararlı olacaktır. Lütfen bu tür sorunları doğrudan posta listemiz aracılığıyla bize bildirin: mercurial.selenic.com/wiki/MailingLists veya hata izleyici: selenic.com/mercurial/bts Bu, burada yayınlamaktan çok daha üretken :-)

— Martin Geisler

4

Mercurial'ın (1.5'ten beri) son sürümleri gelen verilerin doğrulanmasını destekler. Ekle

[server]
validate = True

.hg/hgrcsunucunun gelen verileri doğrulaması ve geçersiz pushları reddetmesi için hg config (ya da hgwebdir config düzgün çalışmalıdır). Müşteri daha sonra aşağıdakine benzer bir hata görür:

remote: abort: missing file data for beta:dddc47b3ba30e54484720ce0f4f768a0f4b6efb9 - run hg verify

Umarım yardımcı olur!

— durin42
kaynak

2

Belki de depoya tamamen gitmekten kaçınmalısınız. Mercurial ve dağıtılmış doğası ile herkes kendi şubesine sahip olabilir ve hazır olduklarını hissettiklerinde size söylerler ve siz onlardan çekersiniz. Taahhüt erişimi sorunu yok, işleri kıracak bir baskı yok ...

Bu en azından SVN'den Mercurial'a göç ederken bir arkadaşımın bana verdiği bir tavsiye.

Bilmiyorum, bu sizin için bir seçenekse, ancak herkes için kişisel bir havuz oluşturmak ve daha sonra ihtiyacınız olan insanlardan çekmek, tehlikeli itme yakalamaya çalışmaktan daha az iş gerektirebilir.

— AdamTheCamper
kaynak

HG'ye itmemek tüm amacını yendi - birden fazla kullanıcı birlikte çalışıyor

— Anonymouse

0

David Herron'un Blog'uyla aynı şeyi yapamaz mıydınız, ancak bunu ön plana çıkarmak yerine, merkezi repodaki ön taahhüt kancasında mı yaparsınız?

— Ryan Gibbons
kaynak

Hayır :-( Bunu denedim ama bir kilitlenme ile sonuçlandı. Bir istemci onu itmeye çalıştığında depoda bir kilit ayırır. sonsuz bir döngü.

— bobinabottle

Ayrıca, bu ön komuta üzerinde çalışsa bile, deposu doğrular, tamam olduğunu görür, sonra bozacak değişiklikleri yapar. Gerçekten, gelen değişikliklerin depoları bozup bozmayacağını değerlendirmek için bir kancaya ihtiyacım var, eğer işlemi geri alırlar. Bu nedenle, değişiklik grubu kancasında olmak daha anlamlı olur.

— bobinabottle

(Değişiklik grubu kancasının kullanılması hala kilitlenmelere neden olur)

— bobinabottle

İlginç - kancalar python tabanlı görünüyor. Depoyu neyin bozduğunu biliyor musunuz? Her seferinde aynı şey mi?

— Ryan Gibbons

0

Olası bir alternatif:

Depoyu itmeden SONRA klonlayın.
Doğrulayın.
Eğer referans iyi ise, en son iyi olan olarak arşivleyin
Depo bozulursa, bir alarm verin
Alarm durumunda, bilinen en son emniyeti geri yükleyin.

Bu çözüm, ihtiyacınız olan şey değildir, ancak en azından, bozulma durumunda deponuzu geri almanın bir yolunu elde edersiniz.

— Laurent Etiemble
kaynak