Una pratica comune per i tag SVN consiste nel taggare diverse versioni per poterle trovare facilmente in seguito. A quanto ho capito, il tagging è la stessa cosa della ramificazione, che in due casi crea semplicemente una copia del trunk in una directory separata (sarebbe branches/something o tags/1.2.3 ), il che significa che:
-
Non c'è alcun impatto sulla quantità di dati memorizzati da SVN stesso (escludendo alcuni byte che indicano che un tag specifico corrisponde a una revisione specifica). Se il dump era 800 MB senza il tag, sarà ancora 800 MB più pochi byte con il nuovo tag.
-
I file vengono duplicati su disco al momento del ritiro. Un progetto che richiede 30 MB su disco impiegherà 60 MB una volta creato il tag.
Significa che:
-
Una volta creato un tag, ogni sviluppatore del mio team riceverà molti dati da SVN la prossima volta che aggiornerà.
-
Con dozzine o centinaia di tag (come succede di solito quando tagghi ogni versione), i checkout possono richiedere ore anche per un piccolo progetto.
Non è così problematico? Non potrebbe essere implementato in modo diverso, ad esempio attraverso svn propedit ? Ci sono casi validi in cui ha senso verificare il tag ogni , invece di uno solo?
Nota: come qualcuno che utilizza costantemente la distribuzione continua, non ho mai usato i tag in pratica, poiché ogni commit è potenzialmente distribuito in produzione se supera i test. Ciò significa che potrei aver perso qualcosa di fondamentale sui tag o sui loro interni, e mi dispiace se questo è il caso. Il mio interesse verso i tag deriva dal fatto che ho passato le ultime due ore a controllare un piccolo progetto di terze parti che ha oltre duecento tag.