Mercurial e codici recensioni; buon flusso di lavoro?

Question

Sono in un piccolo team distribuito usando Mercurial per un repository centrale. Noi ogni clone via ssh su nostre macchine Linux. Il nostro intento è quello di rivedere il lavoro altrui prima di spingere le modifiche fino al repository centrale, per aiutare a mantenere di centrali punta pulita. Che cosa è un buon modo per condividere codice tra gli sviluppatori su diverse macchine Linux? Sono nuovo di Mercurial. Le opzioni che posso pensare (attraverso la lettura, non l'esperienza) sono:

1: Autore impegna tutte le modifiche locali e gli aggiornamenti clone che funziona con la punta della centrale. Autore usa fascio hg, se c'è un modo per specificare quali giri locali da includere nel pacchetto. (Un esperimento mi ha mostrato "bundle" afferra solo le modifiche uncommited, anche se ci sono precedenti commit locali che centrali non conosce) Autore ottiene file del pacchetto di revisore. Recensore crea un nuovo clone pulito dalla punta di centro, e le importazioni il bundle in quel clone. o,

2: Dopo che entrambi autore e revisore recuperare dalla punta di centro, di patch usi autore e le importazioni revisore la patch. o,

3: spinte Autore di revisore o revisore tira da autore (ma come, esattamente Quello che ho letto è solo circa spingendo e tirando da / per l'originale servito repository, e / o sulla stessa scatola invece di tra le diverse caselle di Linux? .)

4: Dimenticate revisione del codice prima di spingere al centro; andare avanti e spingere, utilizzando i tag per identificare ciò che è stato recensione o no, e utilizzare Hudson (già al lavoro) per contrassegnare l'ultima build di sicurezza in modo da membri del team possono sapere che uno per tirare da.

Se il tuo team utilizza Mercurial e fa le revisioni del codice, come si fa a ottenere il recensore per visualizzare le modifiche?

Answer 1

La maggior parte di questi sono possibili, alcuni sono più noioso di altri.

1. È possibile utilizzare fascio specificando la punta di un repo centrale come la --base:
   hg bundle --base 4a3b2c1d review.bundle
2. potrebbe anche solo usare bundle. In questo modo, è anche incluso i dati di modifiche.
3. Si può spingere (e pull) a (da) qualsiasi repository che ha un antenato comune (s). Se si vuole tirare da uno dei suoi colleghi, hanno solo bisogno di correre hg serve sulla loro macchina, e sarete in grado di tirare.
4. Questo funziona anche, ma si dovrà mantenere teste multiple e fai attenzione a fusione. Se non lo fai, può diventare facile basare un cambiamento stabile in cima ad un insieme di modifiche non recensiti, che renderà più difficile da recuperare se avete bisogno di correggere quel changeset non recensiti in seguito.

Tra le opzioni che ha presentato, # 1 e # 3 sono probabilmente più facile, basta a seconda se o non si può raggiungere l'altro di scatole.

In una nota correlata: Questa è la domanda che ha ottenuto il mio collega e ho iniziato a sviluppare Kiln , il nostro (Fog Creek di ) Mercurial hosting e strumento di revisione del codice. Il nostro piano, e il prototipo iniziale, avrebbe mantenuto più repository di tutto, una repository "centrale", e un mucchio di repository "revisione". Il processo di revisione sarebbe iniziato clonando il repo centrale, in una recensione di pronti contro termine sul server, e quindi eseguire un diff repo completa tra i due, con una semplice interfaccia web per ottenere e la visualizzazione dei diff.

Abbiamo evoluto che il flusso di lavoro un po ', ma l'idea generale, avendo un repo ramo per spingere le modifiche non esaminate per e un'interfaccia di rivederli prima di spingere nella repo centrale, è sempre lo stesso. Non voglio pubblicizzare qui, ma mi faccio consigliare dargli una prova .

Answer 2

La metà risposta a questa domanda sta usando ReviewBoard con Mercurial estensione . Esso consente di spingere alcune revisioni per la revisione con il comando seguente

  

hg tip postreview

Answer 3

io aggiungo una quinta opzione - fare tutto il lavoro di sviluppo sui rami con nome, preferibilmente uno per ogni compito. Permettere a nulla di essersi impegnata in un "sviluppo" di nome ramo, sia che si tratti in stato di lavoro o meno.

Push-to repository centrale, hanno revisore tirare il ramo. Eseguire la revisione sul ramo.

Quando la revisione è passato, unire il lavoro di sviluppo nel ramo funzione appropriata.

Questo flusso di lavoro, che è (per me) sorprendentemente impopolare, ha molti vantaggi:

1. Tutto il lavoro viene impegnato -. Non c'è bisogno di aspettare per una revisione per essere fatto prima di commettere

2. Non sarà costruire fuori la versione errata. È sempre e solo costruire dal ramo di caratteristica.

3. Nel corso lavoro non interferisce con altri sviluppatori.

4. Dal ramo di sviluppo, è possibile esaminare le ultime modifiche (ad esempio, i gruppi di modifiche di indirizzamento commenti di revisione), confrontare con il punto di diramazione, o confrontare con l'ultima ramo di caratteristica - ognuno dei quali può dare informazioni utili.