Corrupção de repositório do Mercurial

Question

Isso está relacionado de alguma forma a esta questão , mas é uma pergunta diferente.

Temos um repositório Hg central, servido aos usuários via SSH e servidor-mercurial . 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 então o empurrou de volta para o central, corrompendo-o. Eu quero escrever um script de gancho de entrada no repositório central para evitar que uma transação seja aceita se corromper o repositório central.

Embora infelizmente eu não saiba o suficiente sobre o Mercurial para escrever um roteiro assim. Alguma possibilidade de alguém ter se deparado com isso? Pessoalmente eu não sei ao certo por que o hg não faz isso por padrão.

    

Answer 1

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

[server]
validate = True

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

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

Espero que ajude!

    

Answer 2

Talvez você devesse evitar o envio ao repositório. Com o Mercurial e sua natureza distribuída, todo mundo pode ter sua filial, e quando eles sentem que estão prontos, eles lhe dizem e você puxa deles. Nenhum problema de acesso de commit, nenhum push que vai quebrar as coisas ...

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

Eu não sei se isso é uma opção para você, mas a configuração de um repositório pessoal para todos e a retirada das pessoas de que você precisa podem exigir menos trabalho do que tentar adotar ações perigosas.

    

Answer 3

Você não poderia fazer o mesmo que Blog de David Herron , mas em vez de fazê-lo no pré-site, faça isso no gancho de pré-compromisso no repositório central?

    

Answer 4

Uma alternativa possível é:

1. Clone o repositório APÓS o envio.
2. Confirme-o.
3. Se o repositório estiver bom, arquive-o como o mais recente bom
4. Se o repositório estiver corrompido, ative um alarme
5. Em alarme, restaure o último repositório válido conhecido.

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