Corruption du référentiel Mercurial

14

C'est quelque peu lié à cette question mais c'est une question différente.

Nous avons un référentiel Hg central, servi aux utilisateurs via SSH et mercurial-server . Nous avons un certain nombre de clients Mac, Linux et Windows qui s'y connectent.

Il est arrivé deux fois maintenant que l'un des utilisateurs de Windows a corrompu son référentiel, puis repoussé vers le central le corrompant. Je veux écrire un script de hook entrant sur le référentiel central pour empêcher qu'une transaction ne soit acceptée si elle corrompait le référentiel central.

Bien que je ne connaisse malheureusement pas suffisamment Mercurial pour écrire un tel script. Est-il possible que quelqu'un d'autre soit tombé sur cela? Personnellement, je ne sais pas trop pourquoi hg ne le fait pas par défaut.

mercurial corruption

— bobinabottle
source

J'ai trouvé une solution ici: davidherron.com/blog/topics/… qui devrait être effectuée sur tous les clients. Mais si quelqu'un a une meilleure solution qui peut le faire pour le référentiel central lui-même, ce serait mieux.

— bobinabottle

Veuillez nous donner plus de détails: quelle version de Mercurial utilisez-vous sur le serveur et sur chacun des clients?

— Martin Geisler

2

De plus, il serait extrêmement utile pour nous (les développeurs Mercurial) si vous pouviez reproduire cela. Veuillez également nous signaler ces problèmes directement via notre liste de diffusion: mercurial.selenic.com/wiki/MailingLists ou le suivi des bogues: selenic.com/mercurial/bts C'est beaucoup plus productif que de publier ici :-)

— Martin Geisler

4

Les versions récentes de Mercurial (depuis la 1.5) prennent en charge la validation des données entrantes. Ajouter

[server]
validate = True

à la configuration hg de votre serveur ( .hg/hgrcou la configuration hgwebdir devrait fonctionner correctement) pour que le serveur vérifie les données entrantes et refuse les push non valides. Le client verra alors une erreur semblable à:

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

J'espère que cela pourra aider!

— durin42
source

2

Vous devriez peut-être éviter de pousser complètement vers le référentiel. Avec Mercurial et sa nature distribuée, tout le monde peut avoir sa branche, et quand ils se sentent prêts, ils vous le disent et vous vous retirez d'eux. Pas de problèmes de commit-access, pas de push qui va casser des trucs ...

C'est au moins un conseil qu'un de mes amis m'a donné lors de ma migration de SVN vers Mercurial.

Je ne sais pas, si c'est une option pour vous, mais la mise en place d'un référentiel personnel pour tout le monde et puis retirer des personnes dont vous avez besoin pourrait nécessiter moins de travail, que d'essayer d'attraper des poussées dangereuses.

— AdamTheCamper
source

Ne pas pousser à HG va à l'encontre de son objectif - plusieurs utilisateurs travaillant ensemble

— Anonymouse

0

Ne pourriez-vous pas faire la même chose que le blog de David Herron , mais au lieu de le faire lors du pré-routage, faites-le sur le crochet de pré-validation du dépôt central?

— Ryan Gibbons
source

Non :-( J'ai essayé cela, mais cela se retrouve dans un blocage. Lorsqu'un client tente de le pousser, il réserve un verrou sur le référentiel. L'exécution d'une vérification hg nécessite également un verrou, donc il finit par attendre pour toujours dans une boucle sans fin

— bobinabottle

De plus, même si cela fonctionnait sur le pré-engagement, il vérifierait le référentiel, verrait qu'il est correct, puis validerait les modifications qui le corrompraient. Vraiment, j'aurais besoin d'un crochet pour évaluer si les modifications entrantes corrompraient les dépôts, si c'est le cas, annulez la transaction. Il serait donc plus logique d'être sur le crochet du groupe de changement.

— bobinabottle

(L'utilisation du crochet changegroup entraîne toujours des blocages)

— bobinabottle

Intéressant - les crochets semblent être basés sur python. Savez-vous ce qui endommage le référentiel? Est-ce la même chose à chaque fois?

— Ryan Gibbons

0

Une alternative possible est de:

Clonez le référentiel APRÈS le push.
Vérifiez-le.
Si le référentiel est bon, archivez-le en tant que dernier bon
Si le référentiel est corrompu, déclenchez une alarme
En cas d'alarme, restaurez le dernier bon référentiel connu.

Cette solution n'est pas ce dont vous aviez besoin, mais au moins, vous obtenez un moyen de restaurer votre référentiel en cas de corruption.

— Laurent Etiemble
source