Corruzione del repository mercuriale


14

Questo è in qualche modo correlato a questa domanda, ma è una domanda diversa.

Abbiamo un repository Hg centrale, servito agli utenti tramite SSH e mercurial-server . Abbiamo un numero di client Mac, Linux e Windows collegati ad esso.

È successo due volte ora che uno degli utenti di Windows ha corrotto il proprio repository, quindi è tornato a quello centrale corrompendolo. Voglio scrivere uno script hook in arrivo sul repository centrale per evitare che una transazione venga accettata se danneggerà il repository centrale.

Anche se sfortunatamente non so abbastanza di Mercurial per scrivere una sceneggiatura del genere. Qualche possibilità che qualcun altro si sia imbattuto in questo? Personalmente non sono del tutto sicuro del perché hg non lo faccia per impostazione predefinita.


Ho trovato una soluzione qui: davidherron.com/blog/topics/… che dovrebbe essere fatto su tutti i clienti. Ma se qualcuno avesse una soluzione migliore da fare per il repository centrale stesso, sarebbe meglio.
bobinabottle,

Forniscici maggiori dettagli: quale versione di Mercurial stai utilizzando sul server e su ciascuno dei client?
Martin Geisler,

2
Inoltre, sarebbe estremamente utile per noi (gli sviluppatori Mercurial) se tu potessi riprodurlo. Vi preghiamo inoltre di segnalarci tali problemi direttamente tramite la nostra mailing list: mercurial.selenic.com/wiki/MailingLists o bug tracker: selenic.com/mercurial/bts Questo è molto più produttivo della pubblicazione qui :-)
Martin Geisler,

Risposte:


4

Le versioni recenti di Mercurial (dal 1.5) supportano la convalida dei dati in arrivo. Inserisci

[server]
validate = True

alla configurazione hg del server ( .hg/hgrco la configurazione hgwebdir dovrebbe funzionare correttamente) per fare in modo che il server verifichi i dati in arrivo e rifiuti push non validi. Il client vedrà quindi un errore simile a:

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

Spero possa aiutare!


2

Forse dovresti evitare di spingere del tutto nel repository. Con Mercurial e la sua natura distribuita, tutti possono avere il loro ramo e quando si sentono pronti, te lo dicono e tu ti allontani da loro. Nessun problema di accesso commit, nessuna spinta che romperà le cose ...

Questo è almeno un consiglio che un mio amico mi ha dato quando stavo migrando da SVN a Mercurial.

Non lo so, se questa è un'opzione per te, ma creare un repository personale per tutti e poi attirare le persone di cui hai bisogno potrebbe richiedere meno lavoro, che cercare di catturare spinte pericolose.


Non spingere verso HG sconfigge il suo intero scopo - più utenti lavorano insieme
Anonymouse il

0

Potresti non fare la stessa cosa del Blog di David Herron , ma invece di farlo sul pre-indirizzamento, fallo sul gancio pre-installazione sul repository centrale?


No :-( L'ho provato ma finisce in un deadlock. Quando un client tenta di spingerlo, si riserva un blocco sul repository. L'esecuzione di un 'hg verifica' richiede anche un blocco, quindi finisce solo per aspettare per sempre un ciclo infinito.
bobinabottle

Inoltre, anche se funzionasse su pre-commit, verificherebbe il repository, vedrebbe che è ok, quindi commetterebbe le modifiche che lo corromperebbero. Avrei davvero bisogno di un hook per valutare se le modifiche in arrivo avrebbero danneggiato i repository, in tal caso ripristinare la transazione. Quindi avrebbe più senso essere agganciati al gruppo di discussione.
bobinabottle,

(L'utilizzo del hook del gruppo di modifiche comporta ancora deadlock)
bobinabottle,

Interessante: gli hook sembrano essere basati su Python. Sai cosa sta corrompendo il repository? La stessa cosa ogni volta?
Ryan Gibbons,

0

Una possibile alternativa è:

  1. Clonare il repository DOPO il push.
  2. Verificarlo
  3. Se il repository è valido, archiviarlo come l'ultimo valido
  4. Se il repository è danneggiato, emettere un allarme
  5. In caso di allarme, ripristinare l'ultimo repository valido noto.

Questa soluzione non è quella richiesta, ma almeno ottieni un modo per ripristinare il tuo repository in caso di corruzione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.