Procedura consigliata per la revisione del codice con mercurial

In genere abbiamo utilizzato Perforce e SmartBear's Code Collaborator presso Big Corpe ora utilizzeremo anche Mercurial per determinati progetti.

Supporto di Code Collaborator Mercurial (stiamo utilizzando la versione 5) e sto cercando di determinare quando il momento migliore (durante il commit / push sul server) è il momento migliore / efficiente per una revisione del codice

Grazie

code-reviews mercurial

— cbrulak
fonte

Probabilmente dovresti separare le due domande. (a) appartiene qui, ma (b) probabilmente appartiene a stackoverflow o serverfault

— blueberryfields

Grazie @blueberryfields. in realtà ho risolto il problema, il problema era con il file bin / hg.cmd che si trovava nel percorso e non l'exe.

— cbrulak,

Risposte:

Di recente abbiamo passato quasi esattamente la stessa cosa nella mia azienda. Ecco cosa abbiamo fatto:

Conserviamo una copia definitiva centrale di tutti i nostri repository su un server. Quando gli sviluppatori vogliono "estrarre" il codice, vanno su questo server e clonano dai repository lì. Allo stesso modo, quando il ciclo di sviluppo è completo, il codice viene inserito anche nel repository appropriato.
Separiamo stabili repository di sviluppo repository. È necessario che il codice sia rivisto prima di essere inserito in un repository stabile. (Ciò è significativo perché richiediamo anche che i nostri repository stabili contengano il codice che è attualmente in esecuzione in produzione, differendo solo per le promozioni di codice in sospeso.)

Per imporre la revisione del codice, abbiamo scritto un pretxnchangegrouphook (documentato nel libro di HG ). Sfruttiamo il fatto che quando questo hook viene eseguito, può vedere il repository come se le modifiche al codice fossero permanenti, ma ci dà anche la possibilità di impedire il push. Fondamentalmente, il processo è il seguente:

Lo sviluppatore avvia una spinta al repository stabile (sì, questo è davvero il primo passo)
L'hook esegue e prende un elenco di tutti i changeset inclusi nella transazione (eseguendo il registro HG). Quindi esegue una query su un database creato per vedere se tali cambiamenti sono stati inclusi in una revisione del codice. (La tabella corrisponde all'hash di un changeset con un ID di revisione del codice).
- Se è la prima volta che viene visualizzato uno qualsiasi di questi changeset, creiamo una nuova revisione del codice (usando la riga di comando di Code Collaborator), quindi registriamo questi cambiamenti nel database con l'ID di quella revisione del codice.
- Se abbiamo visto alcuni (ma non tutti) i changeset, eseguiamo il comando (Code Collaborator) per allegare i nuovi changeset alla revisione esistente e registrare questi nuovi changeset nel database.
- Se tutte le modifiche sono state rilevate nel database (ovvero, sono state tutte aggiunte alla revisione del codice), verifichiamo che lo stato della revisione del codice sia Completo. Tuttavia, se ci fossero nuovi changeset (o la revisione del codice non è completa), l'hook esce con un codice di stato diverso da zero (facendo sì che Mercurial ritorni indietro alla transazione) e genera un messaggio amichevole su Errore standard che spiega allo sviluppatore che la revisione del codice deve essere terminata.

In sostanza, ciò fornisce allo sviluppatore un processo piuttosto semplificato (tutto ciò che deve fare è premere hg) e automatizza completamente la creazione della revisione del codice (e il caricamento di ulteriori file modificati nella revisione), garantendo al contempo che tutto il codice venga esaminato .

Nota: questo è un processo abbastanza semplice (e relativamente nuovo per noi), quindi potrebbe non funzionare per tutti e potrebbero esserci alcuni bug di progettazione che non abbiamo ancora riscontrato. Ma finora, ha funzionato abbastanza bene.

— Ryan
fonte

Spiegheresti la tua decisione di fare il check-in nel tuo ambiente stabile prima della revisione del codice? Per me, stabile sembra essere un termine improprio.

— Giordania,

Probabilmente non era chiaro dalla risposta, ma in realtà non lo fa nel repository a meno che tutte le modifiche non siano state aggiunte alla revisione del codice e la revisione non sia completa. Se l'hook esce con un codice di uscita diverso da zero, Mercurial esegue il rollback di tutte le modifiche che sono state inviate. Pertanto, quel particolare hook fornisce un posto molto conveniente non solo per ottenere le differenze per la revisione, ma anche per imporre la revisione prima che le modifiche siano consentite nel repository.

— Ryan,

Wow. Posso venire a lavorare per te?

— Ricco

@Ryan - Come implementiamo l'hook pretxnchangegroup, il link che fornisci non fornisce spiegazioni dettagliate su come può essere implementato, non fornisce il tipo di template di funzione che dovremmo seguire, dove mettere l'hook. Non ho esperienza di Python. Per favore, potresti reindirizzarmi a una fonte corretta o al modello per hook pretxnchangegroup. Ta

— Simple-Solution,

Dipende da come hai la struttura del tuo repository e da cosa stai cercando di realizzare. Preferiamo fare recensioni "pre-commit", che nel mondo di DVCS significa davvero "pre-push". I DVCS sono più belli in questo ambiente (rispetto ai tradizionali SCM) perché hanno funzionalità integrate per salvare le modifiche locali e ripristinare lo spazio di lavoro in modo da poter lavorare su qualcos'altro.

Se si desidera eseguire revisioni post-push, il flusso di lavoro ideale dipende fortemente dalla struttura del repository. Ad esempio, supponiamo che una struttura di repository assomigli a quella discussa in questo articolo sui layout di repository Git . In questo caso, potresti voler rivedere le modifiche che vengono unite develop. I singoli commit sui rami delle caratteristiche potrebbero non avere senso rivedere. Ovviamente tutto hotfixesdeve essere rivisto insieme alle fusioni master.

Se invece hai un singolo ramo di integrazione in cui le persone effettuano il check-in direttamente, vorresti rivedere tutti i push verso quel ramo. Probabilmente è leggermente meno efficiente, ma potrebbe ancora funzionare. In questo ambiente, è necessario assicurarsi che tutte le modifiche che sono state inviate vengano riviste prima di tagliare una versione. Questo può essere più complicato.

Per quanto riguarda b) l'unica cosa che suggerirei è di inviare un'e-mail al supporto SmartBear (support@smartbear.com) direttamente. (Sì, lavoro per SmartBear) saremo felici di aiutarti a risolvere i problemi del tuo percorso, ma non ci sono abbastanza informazioni in questa domanda per risolvere il tuo problema. Il normale processo consiste nell'eseguire l'installer e tutto funziona. Apparentemente qualcosa è andato storto in quel processo.

— Brandon DuRette
fonte