Strumento per la revisione del codice nel repository Mercurial

Question

Nel nostro team si pratica la revisione del codice per ogni commit. Intendo la recensione del codice locale, quando il revisore si trova vicino a te. Con Subversion (abbiamo usato TortoiseSVN) che abbiamo usato per l'ordinamento cambiamenti di set come questo:

Ora usiamo Mercurial (attraverso TortoiseHg). TortoiseHG non supporta il raggruppamento delle modifiche nella directory di lavoro.

I commit locali aiutano un po 'ma c'è ancora un problema con la revisione di una serie di commit locali. Non c'è modo di "contrassegnare" (ad esempio, con le caselle di controllo) i file che sono già stati esaminati.

C'è qualche strumento che risolve questo problema? Inoltre, sarà molto interessante leggere la tua esperienza con la revisione del codice in Mercurial.

Answer 1

Utilizziamo lo strumento Atlassian Crucible Questo è di gran lunga uno dei migliori strumenti di PR e mescolato con tutti gli altri strumenti di Atlassian è facilmente la scelta migliore. Questo può essere economico per una piccola squadra, ancora abbastanza economico per le grandi imprese.

Questo funziona anche se si trasferiscono le modifiche su un repository monitorato. Usiamo efficacemente l'integrazione continua e costruiamo per disabilitare il push del codice ogni notte in modo da poter effettuare le revisioni tra pari e la fusione prima e rapidamente.

Spesso però accoppiamo il programma e per rivedere le modifiche a livello di spalla o catturare le persone, usiamo il nostro IDE (IntelliJ IDEA) o DiffMerge per rivedere le modifiche direttamente sul computer. Questo non è realmente uno strumento di pubbliche relazioni, è uno strumento di diff/merging che usiamo anche per la fusione, ma la combinazione di DiffMerge e Crucible facilita i nostri processi agili abbastanza bene.

Spero che questo aiuti alcuni.

Answer 2

Ci sono molti strumenti di revisione del codice che gestiranno questo - alcuni gratuiti; alcuni pagati Fai una ricerca di "peer code review" e li vedrai tutti. Opterei per qualcosa che permetta anche di riferire sul flusso di lavoro, sui bug trovati, sui tempi di revisione, ecc. Queste informazioni possono essere incredibilmente potenti nel migliorare le prestazioni del team di sviluppo e di sviluppo.

Answer 3

vedo almeno due modi per eseguire la revisione del codice a Mercurial | TortoiseHg:

• senza utensile 3rd-party
• utilizzando prodotti aggiuntivi

CodeReview interno

Solo Mercurial e i suoi rami nominati usati in questo caso. Flusso di lavoro e accordi preliminari * Il ramo predefinito è un ramo di tipo merge. Tutto lo sviluppo avviene in separata (caratteristica personale?) rami; * Solo i controlli di qualità attendibili hanno diritti di unione su valori predefiniti;

Funziona

1. Quando DEV vuole mostrare alcuni gruppi di modifiche dal ramo di caratteristica di QA, ha spingere ramo in questione (hg push -b) a QA (o QA ramo pull)
2. ogni changeset rivisto (o l'intero ramo dopo aver esaminato tutti i bundle) fuse in default (o qualsiasi altro ramo "mainline") e di default ha spinto a "autorevoli repository", da cui "ha accettato le modifiche" può essere trainato da tutti gli altri sviluppatori

CodeReview con strumenti esterni

ReviewBoard

TortoiseHg da 2,0 dialogare ReviewBoard, integrati nel Workbench UI. È possibile scaricare, installare, configurare ReviewBoard (attenzione - Django) oppure registrati per RBCommons (ospitato ReviewBoard) e dopo seguire questa small HowTo al fine di ottenere TortoiseHg e ReviewBoard integrazione

Assembla, BitBucket

Con i repository biforcati e le richieste pull è possibile avere anche CodeReview (in una certa misura)

Answer 4

Se si sviluppa utilizzando Mercurial + Visual Studio, posso consigliare Review Assistant.

Lo usiamo per la revisione del codice nella nostra azienda. Facciamo principalmente la revisione del codice post-commit.

Inoltre, è possibile impostare l'integrazione con TortoiseHG.

Answer 5

necessario un metodo per gli sviluppatori all'interno di team locali per essere in grado di impacchettare le loro modifiche e inviarle per la revisione. Ecco la gara di apertura:

Dev A: hg diff > uncommited.patch

Dev B: hg patch --no-commit uncommited.patch