Qualunque convenzione riconosciuta per i registri di archivio dei repository?

Question

Qualunque convenzione riconosciuta per i registri di archivio dei repository?

#1 da (2 voti)
#2 da (1 voti)

6

Usiamo TortoiseSVN, ma non abbiamo un sistema di tracciamento dei bug. Lo so, zoppo, ma al di là del mio controllo.

Ci sono stati momenti in cui svn non era in uso quotidiano. Ora sono riuscito a premere per usarlo regolarmente, con fusioni, ramificazioni, tagging, ecc.

Come ci si potrebbe aspettare, il numero di revisioni è aumentato nel risultato, il che rende il log del browser di esplorazione un po 'problematico ora.

Ho pensato di utilizzare alcune convenzioni basate su parole chiave ("[bugfix]", "[feature]", "[refactored]", "[minor]", "[merged-from-trunk]" ...: ) in modo da renderlo più ricercabile.

Tuttavia, sembra di dover reinventare la ruota. C'è una convenzione stabilita per questo? O il mio approccio è sbagliato dall'inizio? Qualunque migliore soluzione alternativa?

version-control programming-practices svn

posta Konrad Morawski 26.04.2012 - 12:35

fonte

2 risposte

Leggi altre domande sui tag version-control programming-practices svn

I contributori una tantum dovrebbero essere elencati come autori? Rilevazione di perdite di codice Internet [chiuso]

score 2 · Answer 1

Se hai un ID univoco per bug o ticket, allora un modello comune è quello di aggiungere # 123 a un messaggio di commit se corregge il bug con 123 o la funzione 123 di implementazioni.

Spesso i tracker di bug hanno dei ganci di commit che aggiungeranno il log di commit nel bug tracker o sistema di ticketing basato su questo 'tag'. Ciò ti consente di trovare i registri di commit 'nel contesto'

Inoltre, hai cercato repository open source per trovare modelli comuni per altri scenari? Puoi cercare Github per un progetto dello stesso tipo e / o piattaforma per vedere se c'è un denominatore comune quando le persone stanno unendo o correggendo bug.

score 1 · Answer 2

Quando facciamo cose che si riferiscono a segnalazioni di problemi esterni (ad esempio, tramite RT o qualsiasi altra cosa) spesso finiamo con la stringa "corregge RT # 12345" o simile se è una correzione di bug.

Per tutto il resto, spesso usiamo Trac (che si integra bene con un repository SVN) e fornisce roadmap, wiki (per la documentazione, ecc.), un sistema di tracciamento dei bug e un browser di revisione / ricerca evidenziato da sintassi / diff.

Una cosa che fa è integrare un tipo di formattazione Wiki con modifiche al changeset, incluso (cosa più importante e pertinente qui) l'applicazione della formattazione wiki al testo nudo del log del changeset. Di conseguenza, puoi inserire la formattazione wiki nel messaggio di commit e fare in modo che funzioni come il collegamento alle revisioni corrette delle filiali che stai unendo, o il collegamento al bug report dei bug effettivi.

Ad esempio, se c'è un errore nel sistema trac che una revisione cambia, diciamo " fixes #124 " e quando si esplora quel changeset tramite trac, si trasforma effettivamente " #124 " in un collegamento al bug # 124. Allo stesso modo se diciamo " merges [37:54/branches/featurex] " lo trasforma in un link al browser sorgente per /branches/featurex che mostra i changeset tra la revisione 37 e la revisione 54, con l'opzione di selezionare prima e ultima e mostra solo tutte le modifiche tra le revisioni iniziale e finale .

Sono disponibili ulteriori informazioni sul tipo di link interni che puoi creare nei check-in qui:

link

Spero che ti aiuti!