Корупція в репозиторії Меркурія

14

Це дещо пов'язане з цим питанням, але є іншим питанням.

У нас є центральне сховище Hg, яке обслуговується користувачами через SSH та mercurial-сервер . До нас підключаються кілька клієнтів Mac, Linux та Windows.

Уже двічі траплялося, що один із користувачів Windows пошкодив свій сховище, а потім відсунув його до центрального. Я хочу написати скрипт вхідного гачка в центральний сховище, щоб запобігти прийняттю транзакції, якщо це пошкодить центральне репо.

Хоча, на жаль, я не знаю достатньо про Mercurial, щоб написати такий сценарій. Будь-яка можливість, що хтось ще натрапив на це? Особисто я не зовсім впевнений, чому hg не робить цього за замовчуванням.

mercurial corruption

— бобінаботлет
джерело

Тут я знайшов рішення: davidherron.com/blog/topics/…, що потрібно зробити для всіх клієнтів. Але якщо у когось є краще рішення, яке можна зробити для самої центральної репо, то було б і краще.

— bobinabottle

Будь ласка, дайте нам детальніше: яку версію Mercurial ви використовуєте на сервері та на кожному з клієнтів?

— Мартін Гейслер

2

Крім того, було б дуже корисно для нас (розробників Mercurial), якби ви могли це відтворити. Будь ласка, повідомте нам про такі проблеми безпосередньо через наш список розсилки: mercurial.selenic.com/wiki/MailingLists або програма відслідковування помилок: selenic.com/mercurial/bts Це набагато продуктивніше, ніж публікація тут :-)

— Мартін Гейслер,

4

Останні версії Mercurial (з 1.5) підтримують перевірку вхідних даних. Додайте

[server]
validate = True

на hg-конфігурацію вашого сервера ( .hg/hgrcабо конфігурація hgwebdir має працювати нормально), щоб сервер перевіряв вхідні дані та відмовлявся від недійсних натискань. Потім клієнт побачить помилку, схожу на:

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

Сподіваюся, що це допомагає!

— дурін42
джерело

2

Можливо, вам слід взагалі уникати натискань на сховища. З Mercurial та його розповсюдженою природою кожен може мати своє відділення, і коли відчує, що готовий, вони скажуть вам, і ви витягнете з них. Жодних проблем із доступом до комісій, жодних натискань, які б порушили речі ...

Це принаймні порада, яку мені дав мій друг, коли я мігрував зі SVN до Mercurial.

Я не знаю, чи це варіант для вас, але налаштування особистого сховища для всіх, а потім витягнення з потрібних вам людей може зажадати менше роботи, ніж намагатися зловити небезпечні поштовхи.

— AdamTheCamper
джерело

Не підштовхуючи до HG, перемагає всю свою мету - кілька користувачів, які працюють разом

— Anonymousmouse

0

Чи не могли б ви зробити те ж саме, що і в блозі Девіда Херрона , але замість того, щоб робити це заздалегідь, зробіть це на гаку попереднього замовлення на центральному репо?

— Райан Гіббонс
джерело

Ні: - Я намагався це зробити, але він закінчується в глухому куті. Коли клієнт намагається натиснути, він резервує блокування в сховищі. Запуск "hg verify" також вимагає блокування, тому він закінчується просто чекати вічно в нескінченна петля.

— bobinabottle

Крім того, навіть якщо це зробило попередній комітет, він би перевірив сховище, побачив, що це нормально, а потім здійснить зміни, які б його пошкодили. Дійсно, мені знадобиться гак, щоб оцінити, чи не будуть вноситись зміни в пошкодження репостів, якщо так відкрутити транзакцію. Тому було б більше сенсу бути на гачку групи змін.

— bobinabottle

(Використання гака змінних груп все ще призводить до тупиків)

— bobinabottle

Цікаво - гачки, здається, засновані на пітоні. Чи знаєте ви, що псує сховище? Щоразу те саме?

— Райан Гіббонс

0

Однією з можливих альтернатив є:

Клоніруйте сховище ПІСЛЯ натискання.
Перевірте це.
Якщо репозиторій хороший, архівуйте його як останнє хороше
Якщо сховище пошкоджено, підніміть сигнал тривоги
На тривогу відновіть найсвіжіший відомий хороший сховище.

Це рішення - це не те, що потрібно, але, принаймні, ви отримуєте спосіб відкатати ваше сховище у випадку корупції.

— Лоран Етьембл
джерело