Ртутное повреждение хранилища

14

Это несколько связано с этим вопросом, но это другой вопрос.

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

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

Хотя, к сожалению, я не знаю достаточно о Mercurial, чтобы написать такой скрипт. Есть ли вероятность того, что кто-то еще сталкивался с этим? Лично я не совсем уверен, почему hg не делает этого по умолчанию.

mercurial corruption

— bobinabottle
источник

Я нашел решение здесь: davidherron.com/blog/topics/… , которое должно быть сделано на всех клиентах. Но если у кого-то есть лучшее решение, которое можно сделать для самого центрального репо, это будет лучше.

— bobinabottle

Пожалуйста, дайте нам более подробную информацию: какую версию Mercurial вы используете на сервере и на каждом из клиентов?

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

2

Кроме того, было бы чрезвычайно полезно для нас (разработчиков Mercurial), если бы вы могли воспроизвести это. Также сообщайте нам о таких проблемах напрямую через наш список рассылки : mercurial.selenic.com/wiki/MailingLists или средство отслеживания ошибок: selenic.com/mercurial/bts. Это гораздо более продуктивно, чем публикация здесь :-)

— Martin Geisler

4

Последние версии Mercurial (начиная с 1.5) поддерживают проверку входящих данных. добавлять

[server]
validate = True

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

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

Надеюсь, это поможет!

— durin42
источник

2

Может быть, вам следует вообще избегать отправки в хранилище. С Mercurial и его распределенной природой у каждого может быть своя ветвь, и когда они чувствуют, что готовы, они говорят вам, и вы отрываетесь от них. Нет проблем с фиксацией доступа, нет толчка, который сломает вещи ...

Это, по крайней мере, совет, который дал мне мой друг, когда я мигрировал из SVN в Mercurial.

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

— AdamTheCamper
источник

Не настаивать на HG побеждает его цели - несколько пользователей работают вместе

— Anonymouse

0

Не могли бы вы сделать то же самое, что и в блоге Дэвида Херрона , но вместо того, чтобы делать это на предварительной маршрутизации, сделать это на крюке предварительной фиксации на центральном репо?

— Райан Гиббонс
источник

Нет :-( Я пробовал это, но это заходит в тупик. Когда клиент пытается выдвинуть его, резервирует блокировку для хранилища. Выполнение 'hg verify' также требует блокировки, поэтому он просто ждет вечно бесконечная петля

— bobinabottle

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

— bobinabottle

(Использование ловушки для группы изменений все еще приводит к тупикам)

— bobinabottle

Интересно - хуки, похоже, основаны на Python. Знаете ли вы, что портит хранилище? Это то же самое каждый раз?

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

0

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

Клонируйте хранилище ПОСЛЕ толчка.
Проверьте это.
Если репозиторий хороший, заархивируйте его как последний хороший
Если репозиторий поврежден, подайте сигнал тревоги
По тревоге, восстановите последний известный хороший репозиторий.

Это решение не то, что вам нужно, но, по крайней мере, вы получаете возможность откатить свой репозиторий в случае повреждения.

— Лоран Etiemble
источник