Corrupção do repositório mercurial

14

Isso está um pouco relacionado a essa pergunta, mas é uma pergunta diferente.

Temos um repositório central de Hg, servido aos usuários via SSH e mercurial-server . Temos vários clientes Mac, Linux e Windows conectados a ele.

Já aconteceu duas vezes agora que um dos usuários do Windows corrompeu seu repositório e depois voltou ao central que o corrompia. Desejo escrever um script de gancho de entrada no repositório central para impedir que uma transação seja aceita se ela corromper o repositório central.

Embora, infelizmente, eu não conheço o suficiente sobre o Mercurial para escrever esse script. Alguma possibilidade de que alguém tenha se deparado com isso? Pessoalmente, não sei ao certo por que o hg não faz isso por padrão.

mercurial corruption

— bobinabottle
fonte

Encontrei uma solução aqui: davidherron.com/blog/topics/… que precisaria ser feita em todos os clientes. Mas se alguém tiver uma solução melhor que possa ser feita para o repo central em si, isso seria melhor.

— 7119 bobinabottle

Dê-nos mais detalhes: qual versão do Mercurial você está usando no servidor e em cada um dos clientes?

— Martin Geisler

2

Além disso, seria extremamente útil para nós (os desenvolvedores do Mercurial) se você pudesse reproduzir isso. Relate esses problemas diretamente conosco através da nossa lista de e- mail : mercurial.selenic.com/wiki/MailingLists ou rastreador de erros: selenic.com/mercurial/bts Isso é muito mais produtivo do que postar aqui :-)

— Martin Geisler

4

Versões recentes do Mercurial (desde a versão 1.5) suportam a validação dos dados recebidos. Adicionar

[server]
validate = True

para a configuração hg do servidor ( .hg/hgrcou a configuração hgwebdir deve funcionar bem) para que o servidor verifique os dados recebidos e recuse os envios inválidos. O cliente verá um erro semelhante a:

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

Espero que ajude!

— durin42
fonte

2

Talvez você deva evitar pressionar o repositório completamente. Com o Mercurial e sua natureza distribuída, todos podem ter sua filial e, quando sentem que estão prontos, dizem a você e você se retira. Sem problemas de acesso de confirmação, sem push que quebrará coisas ...

Este é pelo menos um conselho que um amigo meu me deu quando eu estava migrando do SVN para o Mercurial.

Eu não sei, se isso é uma opção para você, mas configurar um repositório pessoal para todos e depois retirar as pessoas de que você precisa pode exigir menos trabalho do que tentar pegar empurrões perigosos.

— AdamTheCamper
fonte

Não empurrando para HG derrotas todo o seu propósito - vários usuários trabalhando juntos

— Anonymouse

0

Você não poderia fazer o mesmo que o Blog de David Herron , mas, em vez de fazê-lo na pré-rota, faça-o no gancho de pré-confirmação no repo central?

— Ryan Gibbons
fonte

Não :-( Eu tentei isso, mas ele acaba em um impasse. Quando um cliente tenta empurrá-lo, reserva um bloqueio no repositório. A execução de uma 'verificação de hg' também requer um bloqueio, portanto, ele acaba aguardando uma eternidade. um anel sem fim.

— bobinabottle

Além disso, mesmo que isso funcionasse na pré-confirmação, ele verificaria o repositório, verificaria que está tudo bem e confirmaria as alterações que o danificariam. Realmente, eu precisaria de um gancho para avaliar se as alterações recebidas danificariam os acordos de recompra, caso contrário, revertam a transação. Portanto, faria mais sentido estar no gancho do grupo de mudanças.

— bobinabottle

(Usando o gancho changegroup ainda resulta em impasses)

— bobinabottle

Interessante - os ganchos parecem ser baseados em python. Você sabe o que está corrompendo o repositório? É a mesma coisa toda vez?

— 21711 Ryan Gibbons

0

Uma alternativa possível é:

Clone o repositório APÓS o envio.
Verifique isso.
Se o repositório for bom, arquive-o como o mais recente
Se o repositório estiver corrompido, acione um alarme
Em alarme, restaure o último repositório válido.

Esta solução não é o que você precisava, mas pelo menos, você pode reverter seu repositório em caso de corrupção.

— Laurent Etiemble
fonte