Come assicurarsi che le correzioni dei bug in un ramo di versione in Subversion siano unite nel trunk

Question

Stiamo gestendo le nostre versioni del software come diramazioni in Subversion. L'ultima versione imminente è il baule. Le versioni precedenti rilasciate sono un ramo (anche taggato per build e release). Quando uno sviluppatore sta correggendo un bug in una versione precedente, è sua responsabilità fondere la correzione nel trunk. Nel caso in cui questo passaggio venga saltato, è difficile notare fino a quando, forse, l'errore si ripresenta in una versione successiva. Quindi dobbiamo eseguire il debug e sistemarlo di nuovo.

C'è un modo per monitorare le unioni per assicurarsi che siano fatte?

Oppure esiste un modo migliore per utilizzare la ramificazione di Subversion per ottenere risultati migliori.

AGGIORNAMENTO: Le persone hanno indicato che la soluzione dovrebbe includere un sistema di tracciamento dei bug. Usiamo Jira e contrassegniamo ogni commit con l'ID del problema Jira. Nessuna ulteriore integrazione è implementata in questo momento.

È possibile che la soluzione abbia un processo migliore. Ma se ci sono strumenti per supportare questo processo migliore, mi piacerebbe conoscere la loro esistenza o il modo di usarli.

Answer 1

Se i bug sono in un bug tracker (e dovrebbero essere), è possibile utilizzarlo per tracciare questo. Ci dovrebbe essere un modo nel tuo bug tracker per contrassegnare quali versioni sono interessate.

Per assicurarsi che un bug chiuso è in realtà risolto, QA/testing gente dovrebbe test che il bug è in realtà fissata in tutte le versioni supportate.

monitoraggio merge di SVN può aiutare alcuni, ma alla fine non si può dire:

• è stato il bug fissata da una modifica non correlata sul tronco, e questo era necessario nessuna patch?
• la patch del ramo non funziona sul trunk, a causa di altre modifiche?
• la patch del ramo non si applicava affatto al trunk e sul trunk era necessaria una patch diversa?

Il test è davvero il modo migliore per assicurarsi che un bug sia sparito. Se non si hanno persone con il QA/test, è possibile far eseguire uno sviluppatore diverso o assumere tester software.

Answer 2

A partire dalla versione 1.5, SVN inserisce le informazioni sulle revisioni unite nelle proprietà. Dovresti essere in grado di trovarlo lì e dargli un senso. Tuttavia, questo indica solo quali revisioni sono state unite, non quali revisioni sono state dimenticate per unire.

Alla fine, immagino, tutto si riduce a coloro che fanno una correzione su un ramo responsabile anche per la fusione nel bagagliaio. Il modo migliore per assicurarsi che ciò accada è probabilmente la pressione dei pari. :)

Answer 3

Le versioni più recenti di sovversione (credo, a partire da 1.5 o 1.6) hanno un tracciamento unione. Cioè, la sovversione tiene traccia di quale delle modifiche nel ramo sono state unite al tronco.

È possibile unire tutte le modifiche dal ramo al tronco utilizzando il comando:

svn co https://server/repo/trunk 
cd trunk 
svn merge --reintegrate https://server/repo/branches/branch_name 
<check merge results, run unit tests, etc> 
svn commit 

Vedere Subversion manual per maggiori dettagli.

In questo modo si ottengono tutte le modifiche apportate nel ramo per arrivare al bagagliaio. Tuttavia, se non si desidera ottenere tutte le modifiche da un ramo all'altro, è necessario utilizzare svn diff per notare le modifiche e selezionare le modifiche che si desidera unire.

Answer 4

In primo luogo, il modo per essere certi che queste operazioni vengano eseguite è registrare il controllo della correzione sul ramo della versione e il controllo dell'unione sul tronco nella voce del bug nel sistema di tracciamento dei bug. Se non si dispone di un sistema di tracciamento dei bug, ottenerne uno. Oltre ad aiutare con le correzioni di monitoraggio, risolve molti altri problemi con il monitoraggio dello stato dei bug.

In secondo luogo, si potrebbe prendere in considerazione un approccio alternativo. Quando duplichi un bug in una versione rilasciata, prova a duplicarlo anche nella testa del bagagliaio. La maggior parte delle volte scoprirai che si sta ancora verificando. Risolvilo nel bagagliaio e verifica la correzione. Quindi unisci la modifica ai rami per le versioni già rilasciate che richiedono la correzione (potresti dover modificare la correzione per tenere conto del diverso ambiente). Se il bug si verifica solo in un ramo di rilascio, lo aggiusta lì (non è necessario che venga unito al trunk).

Answer 5

Non c'è niente in SVN per dirti quale codice dovresti o non dovresti controllare, ramificare, unire o eliminare. Non è il suo lavoro. Fa perfettamente il suo lavoro - che ti fornisce uno strumento con versione per memorizzare il tuo codice.

Quindi, non hai bisogno di uno strumento per gestire meglio il tuo codice, hai bisogno di un sistema esterno per gestire meglio i tuoi sviluppatori :)

Un modo è QA, test e un inseguitore di bug - mentre vengono apportate modifiche al codice, il fatto che qualcosa sia stato fatto al codice viene registrato e tracciato attraverso le varie fasi. In genere non si desidera che chiunque apporti modifiche al codice senza alcuna ragione (oltre a "ho ritenuto necessario il refactoring"), quindi uno strumento di monitoraggio è comunque una buona idea. Poiché i bug sono corretti in una versione, questo strumento può essere usato per assicurare che il bug sia corretto anche in altri (quando appropriato - a volte non vuoi che una particolare modifica venga apportata a un rilascio)

SVN può integrare con questi strumenti, ad esempio, il mio repository aggiorna il mio bugtracker Mantis quando alcune parole magiche vengono aggiunte a un checkin (se si digita "mantis fisso # 1234" nel commento di checkin, il bug di mantis 1234 verrà aggiornato con i file modificati e il suo stato modificato in attesa di test)

In alternativa strumenti come il diario di bordo possono anche integrarsi - mentre si apporta una modifica, la revisione può essere registrata lì per altri da firmare, il processo di firma può includere la garanzia che il bug sia unito o un una nuova segnalazione di bug viene creata per gli altri rilasci necessari per la correzione.

Quindi, il problema non riguarda SVN, ma i processi di sviluppo.

Answer 6

Si potrebbe voler adattare la strategia che gli sviluppatori di Subversion usano da soli: fare la maggior parte dello sviluppo in baule, rilascio da filiali. Quando viene rilevato un errore, viene prima risolto nel trunk e quindi la correzione viene unita dal trunk al ramo.

Answer 7

Ecco cosa stiamo facendo, ho solo blogged about it - abbiamo configurato una build speciale nel nostro server CI che assicura, su base notturna, che non esistano cambiamenti non contenuti.

Answer 8

In realtà ho scritto una sceneggiatura un po 'di tempo fa per fare esattamente questo. Abbiamo avuto un numero di filiali simultanee in corso su un progetto a cui stavo lavorando, ed è stato molto difficile tenere traccia di tutti i commit e le fusioni.

Potete trovare lo script in: http://github.com/ccampbell/show-missing-revs

Diciamo che avere un ramo di release 2.0. Per scoprire tutto commesso in 2.0 che non è ancora stata fusa al tronco:

cd /path/to/trunk 
sh /path/to/show_missing_revs.sh -b 2.0 -u username (optional) -v (verbose) 

Questa volontà di uscita qualcosa di simile:

r2532 | username | fixing bug with this 
r2631 | username | fixing bug with that 

Ciò richiede la sovversione 1,5 credo. Spero che tu trovi questo utile!