Vantaggio di etichettare una versione in SVN rispetto a lasciare solo un commento per il commit

Un tag in sovversione è tecnicamente lo stesso di un ramo. È solo una convenzione che ti impedisce di modificare un tag dopo che è stato creato.

L'anno scorso ho avuto una situazione in cui eravamo molto contenti di utilizzare i tag in sovversione.
Abbiamo creato una versione e contrassegnato questa versione. In parallelo ai test di accettazione del rilascio, il normale sviluppo è continuato sul trunk del repository. Il problema era che a un certo punto dei test di accettazione si era trovato un problema critico che doveva assolutamente essere risolto, ma il nuovo materiale che si stava sviluppando non poteva assolutamente essere incluso nel rilascio, perché era ben lungi dall'essere abbastanza stabile. > Abbiamo risolto ciò facendo finalmente uso del fatto che sotto il cofano un tag è lo stesso di un ramo, quindi abbiamo apportato la modifica direttamente sul tag. Se avessimo usato i commenti di check-in per "taggare" i nostri rilasci, non sarebbe stato così facile.

Inoltre, se il tuo progetto consiste di più progetti che si evolvono a una velocità diversa ma vengono sempre rilasciati insieme, un tag di sovversione garantisce di avere un'istantanea corretta di tutti i progetti al momento del rilascio, anche se alcuni di loro non sono cambiati dall'ultima versione. Se utilizzi i commenti di check-in per contrassegnare una versione, devi effettuare il check-in su ciascun progetto, anche se non è cambiato nulla.

Alcuni clienti che non possono eseguire l'aggiornamento a una versione più recente richiedono il supporto per la versione x.y.z. Un tag con quella versione ti aiuterà a identificare il codice che devi controllare. Chiedi al nuovo ragazzo di cercare la versione utilizzando i commenti di commit. Per favore, fallo!

Un tag è fatto apposta per essere in grado di ottenere l'istantanea esatta delle fonti nel momento in cui l'hai creata. È 1000000 volte più conveniente di guardare i commenti di invio .... specialmente se la tua versione ha richiesto più commit (o più).

Inoltre, il caso in cui un bug importante è stato rilevato in accettazione o in produzione mentre lo sviluppo è in corso e non abbastanza stabile è abbastanza comune! In tal caso devi creare un ramo. Come altri hanno già detto, un tag è oltre la scena un ramo in SVN quindi sei salvato in quel caso ma il tagging può anche salvarti la vita con altri strumenti perché molti strumenti ti permettono di creare un ramo dal tag (CVS, TFS e sicuramente altri) . Provalo solo con i commenti!

Sì, è possibile utilizzare il numero di revisione per identificare in modo univoco un'istantanea nel tempo.

Ma ... dove registrate quale revnum corrisponde a quale versione? Manterrai un foglio di calcolo che dice "versione 4.2.1" è Revnum 18345? Non consigliato.

Tuttavia, la creazione di un tag "ramo" fa esattamente questo senza la necessità di fogli di calcolo o strumenti esterni: se ricordi che un ramo in SVN è solo una copia dello stato del repository (come un link simbolico), ti accorgi che un Tag è non molto più di un puntatore alla revisione che vuoi ricordare. Ottieni tutti i benefici di un'istantanea nel tempo, ma con il vantaggio di poter nominare qualcosa di significativo.

Hai anche altri vantaggi, dato che è un ramo, puoi apportare correzioni di patch ad esso. Il codice fatto per il trunk può essere unito ad esso quando necessario. È possibile creare un nuovo ramo da quel ramo in modo da poter creare un prodotto a forcella se necessario. Puoi passare la tua copia di lavoro alla versione Tagged con un singolo comando. Tutto questo può anche essere fatto registrando il revnum, ma è molto più facile usare un Tag, e dato che non costa nulla, potresti anche optare per l'opzione facile.

Un altro motivo per utilizzare i tag anziché i numeri di revisione per tenere traccia di ciò che è stato rilasciato è che è più semplice mantenere collegamenti / riferimenti ai tag piuttosto che revisioni di trunk (o rami). I riferimenti a determinati percorsi in alcune vecchie revisioni possono interrompersi se si riorganizza il layout della cartella trunk (o ramo) in futuro. I tag non cambiano (per convenzione), quindi non hanno questo problema.