gestione dei rilasci in SVN

Question

Quando mi guardo allo SVN log Mi piacerebbe che ho potuto vedere i marcatori che mi dicono quando rilasci sono stati fatti. Ho visto questo in altri sistemi di controllo versione, come PVC e Perforce .

Può questo essere fatto in SVN? Ho fatto un po 'di ricerca e finora sembra che questo genere di cose non è supportato.

Modifica

Non voglio avere a copiare la nostra fonte in una cartella diversa per ogni release. Questo si traduce in una grande quantità di inutili duplicazioni di file sulla macchina sviluppatori e solo ci dà una registrazione del numero di revisione di ogni release. Posso farlo utilizzando un documento di testo!

Edit2

Il mio obiettivo è quello di avere un unico punto di vista che mi mostra una cronologia delle mie uscite, tra i quali posso vedere tutte le modifiche di codice che hanno avuto luogo tra ogni release. Questo poi rende più facile per compilare le note di rilascio.

Answer 1

Richard, i tag sono molto vicini, ma mi chiedo se quello che vi serve potrebbe non essere un ramo di release dedicata.

Per questo, fare un ramo dal tronco presto chiamato qualcosa come 'uscita'. Quindi lavorare sul tronco come al solito, quando si è pronti per un rilascio, unire le modifiche dal tronco in 'uscita'. Questo è l'unico modo in cui è necessario modificare il rilascio.

È quindi possibile contrassegnare dal rilascio se si vuole, non è necessario al 100%.

Ma ciò che questo vi darà è un ramo che ha un sottoinsieme delle revisioni del tronco in esso. Scopri le date di rilascio con:

svn log --stop-on-copy svn://server/project/branches/release

Questo vi darà un elenco delle date di uscita (con le revisioni). Per vedere cosa c'è in ogni versione fare:

svn mergeinfo --show-revs=merged "svn://server/project/trunk" "svn://server/project/branches/release"@<release revision>

Si noti inoltre che per lavorare in questo modo, non si è limitato ad un rilascio strettamente sequenziale di tutto in tronco - ciliegio si possono raccogliere le revisioni, escludendo le revisioni se non si desidera rilasciare loro appena ancora, ma ancora compreso successiva revisioni.

Answer 2

Non in quanto tale. Il modo accettato di fare uscite in SVN è quello di avere una directory "tag", in cui la sorgente di rilascio viene copiato per ogni particolare versione. Per esempio /tags/release-0.11 ... Non c'è nulla ti impedisce di fare scherzi con la directory tags per caso, fuori dalla scatola, ma alcune persone piace impostare pre-commit ganci per prevenire impegna accidentali di stampa Tag.

Ecco un articolo decente descrivendo un processo di rilascio in SVN.

Answer 3

  

Il mio obiettivo è quello di avere un unico punto di vista che   mi mostra una cronologia delle mie uscite,   tra i quali posso vedere tutte le   modifiche al codice che hanno avuto luogo tra   ogni nuova versione.

Avete indagato il grafico di revisione SVN Tortoise? Se si etichetta ogni release (che, come altri hanno fatto notare non comporta la copia dei file, sia sul server o workstation), allora si può vedere tutte le revisioni in ordine cronologico, con i tag che indicano versioni attuali. È possibile diff tra stampa e / o tronco da hilighting le due revisioni a cui sei interessato e selezionando diff dal menu contestuale.

Answer 4

Copia il tronco ad un percorso tag nel repository svn è il modo per raggiungere questo obiettivo. Si tratta di una copia svn, in modo da non finire con i duplicati di file sul server repository SVN. Hai solo i file duplicati localmente se si è scelto di checkout svn un percorso diverso da quello del tronco. Si impegna su quelle copie di lavoro per poi tornare al percorso svn sono stati estratti dal.

Si tratta essenzialmente di una specifica implementazione convenzionale di ramificazione in svn. Date un'occhiata al libro svn on-line per maggiori dettagli.

Answer 5

L'indicatore sarebbe il messaggio di commit scritto quando è fatto un tag per il rilascio (una copia svn ai / tag). Atleast che è il metodo più comune utilizzato.

Answer 6

Anche se Subversion non fornisce la gestione dei rilasci in sé e per sé, strumenti di controllo di versione non sono in genere il compito di questa attività. Quello che state cercando è un / problema / strumento di gestione del cambiamento di attività che può interagire con Subversion.

A tal fine si usa Jira al mio posto di lavoro e ci colleghiamo con Subversion. Jira fornisce una tabella di marcia e il cambiamento della storia che comprende le questioni in ogni release. Ognuno di questi temi è collegamenti con i cambiamenti nel controllo del codice sorgente. Così è possibile collegare i cambiamenti nel codice sorgente con le versioni rilasciate.

Credo che sia generalmente migliore per mantenere questi due strumenti separati. Sebbene Perforce in particolare tenta di legare i due insieme, lo fanno solo semplicemente. Ci sono alcune cose, come inviare email agli utenti di modificare le questioni, l'aggiunta di commenti ai problemi, l'aggiunta di allegati a problemi che sono molto meglio fatto in un pezzo specializzato di software come Jira. D'altra parte Jira non è molto bravo a controllo delle versioni, la fusione e la ramificazione di origine ... che è meglio gestita in un pezzo specializzato di software come Subversion.

Per completezza di informazione, ci sono altri strumenti di Jira come Bugzilla, Trac, IBM Jazz razionale, ecc, che possono fare la stessa cosa con Subversion che Jira fa anche se con diversi livelli di funzionalità.

Answer 7

Date un'occhiata a temi del SVN Libri:

Tag e Navigando in Repository

Tag e rami sono "copy on write", il che significa che non ci sono copie supplementari nel repository. In genere uno sviluppatore individuo non avrebbe bisogno di avere una copia locale a meno che non ne aveva bisogno per una ragione (cioè lo sviluppo su un ramo).

Se si etichetta ogni release, allora si può vedere i tag sfogliando la repository. I link sopra parlare direttamente sugli strumenti da riga di comando, ma ci sono anche strumenti grafici come TortoiseSVN su Windows. È possibile ottenere la storia, fare paragoni, ecc.

Per vedere le modifiche effettuate in un comunicato, si sarebbe solo mostrare un log del tronco dalla revisione del tag che si desidera tornare alla revisione del tag precedente +1. Suona come lavoro extra, ma è abbastanza semplice una volta che ci si abitua ad esso.

Con i nostri strumenti di compilazione, abbiamo anche impegnarsi di un file con alcune informazioni il numero di versione di nuovo al tronco, e il commento ha il numero di versione del build. Se il codice principale è nel bagagliaio, questo può anche funzionare come marker per ciò che è in una build (vedi tra la versione impegna).

Answer 8

+1 per l'utilizzo del messaggio di commit.

Per un progetto che ho creato un utente chiamato SVN build. La macchina di costruzione utilizzato questo login per SVN. Ogni volta che il sistema di compilazione / processo ha fatto un accumulo anche aggiornato un file e lo SVN commit messaggio era la versione / altro identificatore per la compilazione.

Poi abbiamo anche creato un tag per questo build. In questo modo nel bagagliaio abbiamo potuto vedere la costruisce quando / dove si alternano con altri cambiamenti.

Quindi il mio suggerimento (modo più semplice per farlo) è quello di creare un altro file chiamati build (o qualsiasi altra cosa che si desidera) e aggiungere a quello o semplicemente modificarlo nel vostro script di build / processo e quindi controllare nuovamente in / commettono con il nome della versione finale come il messaggio di commit. Semplice. Sarà quindi presentarsi nelle query di storia.

Answer 9

Inoltre, se si sa che le revisioni si confrontano si può fare un diff SVN e si vedrà quali file sono cambiati e come tra le due revisioni.

Non è sicuro circa la configurazione del totale, ma qualcuno menzionate TortoiseSVN. Questo è definitivamente un buon inizio. Io personalmente uso Eclipse con il plug-in subclipse e mi permette di esibisco diff in un ambiente grafico fra le revisioni. Finché hai il tuo progetto può confrontare la vostra qualsiasi revisione a qualsiasi altra revisione e come tale non hai bisogno di avere tutti i tipi di file di duplicazione.

Inoltre, di solito istituito tre directory in ogni repository. Rami, tronco e tag. Come ha fatto notare qualcuno, tag vengono utilizzati specificamente per identificare un rilascio.

Answer 10

ho incontrato lo stesso problema e il modo in cui ho cercato di risolvere il problema per la mia azienda è di avere una cartella 'rilascio' in tronco, questa cartella contiene solo l'eseguibile reale o ciò che deve essere parte della distribuzione.

creo una nuova cartella per ogni release che iniziano con '1.0.0.0' in 'release' cartella e anche tag il codice con lo stesso nome della cartella di rilascio cioè 1.0.0.0 nel caso.

Non sono sicuro se è il modo giusto per farlo, ma si risolve il problema di scoprire eseguibile che ho schierato.

Answer 11

Se si segue la normale convenzione svn di "tag / rami / trunk" alla radice del repository, gli sviluppatori di solito non vorrebbe controllare l'intero repository, solo dal tronco in giù.

Answer 12

mi piacerebbe offrire un approccio diverso che dovrebbe aiutare a risolvere il problema dichiarato: la creazione di note di rilascio e la visualizzazione delle differenze di codice tra le versioni.

Usiamo un'utility chiamata SubWCRev che viene fornito con Tortoise SVN. Abbiamo un evento di post-generazione che afferra il numero di revisione SVN e lo infila in un file - nel caso di siti web abbiamo messo questo in un file chiamato version.html. Poi, in qualsiasi punto nel tempo si può legare il suo rilascio (se questo è il releas attualmente in QA, Prod, o qualsiasi altro ambiente) per il numero esatto di revisione in SVN. Non più tagging, non più chiedendo che cosa è incluso in un comunicato, non più intercettazioni agli sviluppatori di aggiornare un file di versione.

Al fine di determinare ciò che è è stato incluso in un comunicato, è possibile poi basta tirare sui registri SVN dalla revisione X a revisione Y e copiare i commenti in un documento e modificare per fare una bella note di rilascio doc. Lo stesso vale per la revisione del codice o diffing le uscite; è sufficiente utilizzare i numeri di revisione legate al vostro version.html, properties.cs, readme.txt, ecc

Vorrei anche suggerire avere una sorta di repository artefatto per tenere il vostro costruisce. Se si passa a utilizzare il numero di revisione SVN come il numero di versione, si può sempre tornare a quella revisione esatto in SVN che significa che non è necessario tag o copie del vostro sorgente per ogni release, che in giro in SVN.

Answer 13

Cordiali saluti,

copia SVN non è cartaceo, è solo collegandosi quindi non avrà alcun spazio diverso file modificati. E quelle versioni avranno spazio comunque. Quindi la creazione di una copia per ogni rilascio non avrà alcun spazio.