Trac: plug-in di revisione del codice

Question

Sto cercando un plug-in di revisione del codice per l'installazione trac.

ho trovato questi due come il risultato superiore per "trac code review" di query su google

• PeerCodeReview
• CodeReview

sto appoggiato verso PeerCodeReview plugin.

Richiedere alla community SO gli input relativi a questi plug-in per aiutarmi a selezionare quello per la nostra installazione trac.

Se siete a conoscenza di altri plug-in, fatemelo sapere anche a loro. :)

Quello che sto cercando nel plugin

• un modo di annotare il codice con i commenti.
• Approva/Dis-approva; un po 'come un pulsante per informare che il codice deve cambiare. forse viene creato un bug
• Un modo per assegnare la revisione del codice "Attività" a una persona (s).

La prima funzione è richiesta (credo che sia l'intero punto); altri sono opzionali. Posso hackerare trac per ottenere qualcosa di simile da inserire in quel flusso di lavoro. Fiduciosamente! ;)

Answer 1

Eravamo nella stessa situazione.Alla fine abbiamo optato per l'installazione di Review Board in parallelo a Trac. Anche se non è un plugin Trac, è uno strumento eccellente, e finora ne siamo molto contenti.

Ha anche il supporto di base di Trac, in modo che, ad esempio, durante la revisione delle correzioni dei bug, si ottengano collegamenti automatici al ticket Trac.

Answer 2

Nella mia azienda, abbiamo esaminato brevemente il plug-in "peerreview" su TracHacks e ne siamo rimasti molto delusi.

Ci sembra ovvio che un plug-in di revisione del codice sarebbe naturalmente predefinito assumendo che un intero commit di Subversion debba essere sottoposto a revisione del codice. Sfortunatamente, il plug-in di anteprima peer ti obbliga a identificare manualmente le linee di codice che desideri esaminare. Non ti dà nemmeno suggerimenti su quali linee potrebbero essere cambiate con un particolare commit, il che significa che se non inserisci la riga che è cambiata attentamente, potresti finire a rivedere ripetutamente le stesse righe di codice.

Non abbiamo avuto la possibilità di rivedere l'altro plug-in (CodeReviewPlugin) in qualsiasi dettaglio.

Answer 3

Penso che PeerCodeReview sia migliore per quello che vuoi.

Il poster precedente è corretto, tuttavia - è necessario esplorare il repository di origine e selezionare il codice che si desidera rivedere e annotarlo. Non sa nulla di changeset.

Questo va bene se si dispone di qualcuno (come un architetto o un dirigente) che guarda in modo proattivo il codice e identifica le cose che potrebbero essere problematiche.

Non funziona così bene se si desidera rivedere ogni pezzo di codice in relazione a una modifica.

Se siete alla ricerca di qualcosa che associa con commit, e gestisce diff, poi guardare ReviewBoard (a DJango app):

Answer 4

Sono anche deluso con PeerCodeReview. Lega i commenti a una revisione specifica e quando "Reinvia" una revisione più recente per la revisione, stai chiudendo la vecchia revisione e aprendone una nuova - ma tutti i commenti rimangono solo sulla vecchia recensione! Quindi non esiste un modo semplice per vedere un commento insieme alla nuova fonte che lo affronta. Insieme alla totale mancanza di supporto per la revisione di commit/diff, questo rende PeerCodeReview inadatto per me.

Il plug-in CodeReview sembra carino (in realtà non lo ha provato), ma mi manca ancora la possibilità di commentare righe specifiche.

Non è che il mio caso d'uso non fosse la classica "revisione del codice" ma la revisione di un singolo documento LaTeX. Questo ha diversi requisiti:

• Rivedere prima di un commit non è necessario; al contrario, un flusso di lavoro "sottoposto a pipeline" è critico: i commenti di revisione vengono creati quando il revisore ha tempo libero, e indirizzati quando lo scrittore arriva a loro, spesso in commit molto più tardi.

• Sarebbe bello rintracciare quali parti del testo sono state riviste a quali revisioni.
  Questo non è un aspetto critico, in quanto la revisione viene di solito eseguita una sezione alla volta ed è facile da eseguire per il tracciamento manuale.

• Ci sono molti piccoli commenti indipendenti. Ogni commento deve essere rintracciato in modo indipendente, , una singola risoluzione "approva/rifiuta" per un commit.

• La maggior parte dei commenti sono ben localizzato nel file, quindi voglio un flusso che permette il fissaggio loro di luoghi specifici nel file, e dovrebbero mantenere il loro posto quando il file è modificato.

Il flusso Proprio per questo sarebbe di aprire un biglietto per ogni commento, chiudendoli con ganci commettere quando affrontate. L'unico problema è che non esiste un modo semplice per legare un ticket a linee specifiche nel file, rendendolo piuttosto ingombrante. Sono tentato di scrivere un plugin minimalista che leghi i biglietti alle linee sorgente/diff. Qualcun altro gradirebbe una tale bestia?

Quello che probabilmente farò in pratica è mettere i commenti di TODO all'interno della sorgente stessa e non utilizzare l'interfaccia di Trac di fantasia affatto per questo. Il controllo della versione assicurerà che i commenti rimangano nel punto in cui appartengono alle modifiche.

[per LaTeX specificamente, io probabilmente utilizzare i pacchetti todonotes e/o fixme per visualizzare i commenti bene, e forse latexdiff per diff visive.] Io modificare in seguito a riferire come è andata ...

BTW, questo approccio non è limitato ai documenti: ho lavorato con un team che lo ha utilizzato molto per la revisione del codice durante lo sviluppo agile intensivo e ha funzionato abbastanza bene.Avevano un desiderio simile di "canalizzare" il processo di revisione - lo sviluppo deve andare avanti, ma tutte le modifiche devono essere riviste prima di fare un rilascio. La parte più difficile era tenere traccia di ciò che è stato o non è stato rivisto, cosa che è stata fatta taggando le revisioni "pulite" e differenziandole; in retrospettiva, avendo un ramo "revisionato" e il cherry-picking in esso funzionerebbe meglio. (Naturalmente, le domande architettoniche non localizzate andrebbero invece nei ticket Trac, o inizierebbero come commenti TODO e verrebbero migrati in ticket se si rivelassero non banali da indirizzare.)