Migliore pratica per unire/non unire i tag svn

Question

Ho creato un tag denominato v1.5 fuori da un ramo.Dopo alcuni test ho riscontrato alcuni bug e sembra che debba propagare queste modifiche tag/v1.5.Ma vedo alcuni commenti che non suggeriscono tale pratica di aggiornamento o unione di tag.

La mia domanda è quale sia il modo migliore per gestire situazioni come questa.Probabilmente eliminare il tag e ricrearlo dalla revisione della testata del ramo?

Answer 1

Tag, rami, ecc. Non ha senso per la sovversione stessa, sono solo le cartelle e puoi fare qualsiasi cosa tu voglia. Tuttavia, ci sono buone pratiche, e tag significano qualcosa che non si cambia mai. Dovresti avere un flusso di lavoro e attenersi a questo.

Ad esempio, facciamo nuovi sviluppi nel bagagliaio. Quando è pronto, creiamo un ramo, come 1.5, quindi creare tag, come 1.5.1, 1.5.2, 1.5.3, ecc. Aggiungiamo correzioni di bug e creiamo nuovi tag da esso, non aggiungiamo nuove funzionalità per rami, e non cambiamo mai tag. Quindi uniremo i bugfix dal ramo al tronco quando ci sono nuovi sviluppi. È un flusso di lavoro molto comune.

Ecco un articolo più lungo , ciò che ho descritto sopra è chiamato "Stabile Modello di rilascio "Qui, c'è una buona immagine per mostrarti cosa succede dove. Ci sono anche alternative e una lunga discussione. Amo quei grafici, Ecco un altro , Ma è un po 'confuso, le frecce non dovrebbero attraversare tag, i tag dovrebbero sempre essere un vicolo cieco.

Answer 2

la procedura migliore è non eliminare tags infatti i tag non sono fatti per essere toccati sono solo etichette, mentre è vero che tutto è una cartella in qualsiasi repository svn, la pratica è solitamente lavorare su trunk, aggiornamento branches in caso di bug, e andarsene tags come indicatori per la storia lavorativa precedente come riferimento, i rami possono essere utilizzati anche per lavoro separato, la pratica migliore è lavorare con un unico modello di tronco singolo della linea principale ed evitare il più possibile i rami (integrazione della consegna continua), ma nel tuo caso lo farei dirama il tag e aggiornalo, quindi uniscilo nuovamente al trunk. tags sono destinati a restare.quello che farei è copiare il file tag in un branch con il nome del ramo ed eseguire l'aggiornamento lì.allora lo farei merge torna a trunk.per unioni automatiche c'è un'utilità interessante per svn chiamata utilità di fusione automatica

Google e Facebook hanno adottato lo sviluppo basato sul trunk.sviluppo Nei materiali di cui sopra, questi Googler hanno parlato del lavoro su HEAD e del fatto che i check-in su HEAD avvengono in ogni momento.Ashish dice di eseguire il trunk alcune volte verso la fine in una sezione di domande e risposte e menziona l'evitamento di ramificazioni per lo sviluppo in corso (niente a che fare con i rilasci di per sé).Quindi è ufficiale, Trunk Based Development (TBD) è ciò che fa Google, e ragazzi, lo scalano!(http://paulhammant.com/2013/05/06/googles-scaled-trunk-based-development/)

Answer 3

Tag in SVN è (convenzionalmente) SOTTOREE RO.Se è stato modificato dopo aver creato il codice del tag, devi creare nuovo tag da Codice modificato