Corrupción del repositorio mercurial

14

Esto está algo relacionado con esta pregunta, pero es una pregunta diferente.

Tenemos un repositorio central de Hg, servido a los usuarios a través de SSH y mercurial-server . Tenemos varios clientes Mac, Linux y Windows que se conectan a él.

Ha sucedido dos veces ahora que uno de los usuarios de Windows ha corrompido su repositorio, y luego regresó al central corrompiéndolo. Quiero escribir un script de enlace entrante en el repositorio central para evitar que se acepte una transacción si corrompe el repositorio central.

Aunque desafortunadamente no sé lo suficiente sobre Mercurial para escribir un guión de este tipo. ¿Alguna posibilidad de que alguien más se haya encontrado con esto? Personalmente, no estoy muy seguro de por qué hg no hace esto por defecto.

mercurial corruption bobinabottle
fuente
He encontrado una solución aquí: davidherron.com/blog/topics/… que debería hacerse en todos los clientes. Pero si alguien tiene una mejor solución que pueda hacer para el repositorio central en sí, sería mejor.
bobinabottle
Danos más detalles: ¿qué versión de Mercurial estás usando en el servidor y en cada uno de los clientes?
Martin Geisler
2
Además, sería extremadamente útil para nosotros (los desarrolladores de Mercurial) si pudieras reproducir esto. También infórmenos directamente sobre estos problemas a través de nuestra lista de correo: mercurial.selenic.com/wiki/MailingLists o rastreador de errores: selenic.com/mercurial/bts Eso es mucho más productivo que publicar aquí :-)
Martin Geisler

Respuestas:

4

Las versiones recientes de Mercurial (desde 1.5) admiten la validación de datos entrantes. Añadir

[server]
validate = True

a la configuración hg de su servidor ( .hg/hgrco la configuración hgwebdir debería funcionar bien) para que el servidor verifique los datos entrantes y rechace los empujes no válidos. El cliente verá un error similar a:

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

¡Espero que ayude!

durin42
fuente
2

Tal vez debería evitar empujar al repositorio por completo. Con Mercurial y su naturaleza distribuida, todos pueden tener su rama, y ​​cuando sienten que están listos, se lo dicen y usted se retira de ellos. Sin problemas de acceso de compromiso, sin empuje que rompa cosas ...

Este es al menos un consejo que un amigo mío me dio cuando estaba migrando de SVN a Mercurial.

No sé, si esta es una opción para usted, pero configurar un repositorio personal para todos y luego extraer de las personas que necesita podría requerir menos trabajo que tratar de atrapar empujes peligrosos.

AdamTheCamper
fuente
No presionar a HG derrota todo su propósito: varios usuarios trabajan juntos
Anonymouse el
0

¿No podría hacer lo mismo que el Blog de David Herron , pero en lugar de hacerlo en el enrutamiento previo, en el gancho de precompromiso en el repositorio central?

Ryan Gibbons
fuente
No :-( Lo he intentado pero termina en un punto muerto. Cuando un cliente intenta presionarlo, se reserva un bloqueo en el repositorio. Ejecutar una 'verificación de hg' también requiere un bloqueo, por lo que termina esperando para siempre en un bucle sin fin.
bobinabottle
Además, incluso si esto funcionara en el precompromiso, verificaría el repositorio, vería que está bien y luego confirmaría los cambios que lo corromperían. Realmente necesitaría un enlace para evaluar si los cambios entrantes corromperían los repositorios, de ser así, revierta la transacción. Por lo tanto, tendría más sentido estar en el gancho del grupo de cambio.
bobinabottle
(El uso del gancho changegroup todavía da como resultado puntos muertos)
bobinabottle
Interesante: los ganchos parecen estar basados ​​en Python. ¿Sabes qué está corrompiendo el repositorio? ¿Es lo mismo cada vez?
Ryan Gibbons
0

Una alternativa posible es:

  1. Clone el repositorio DESPUÉS del empuje.
  2. Verificarlo
  3. Si el repositorio es bueno, archívelo como el último bueno
  4. Si el repositorio está dañado, active una alarma.
  5. En caso de alarma, restaure el último repositorio bueno conocido.

Esta solución no es lo que necesitabas, pero al menos, obtienes una forma de deshacer tu repositorio en caso de corrupción.

Laurent Etiemble
fuente