Cosa significano "branch", "tag" e "trunk" nei repository Subversion?

Question

Ho visto queste parole molto spesso nelle discussioni su Subversion (e immagino sul repository generale).Ho utilizzato SVN per i miei progetti negli ultimi anni, ma non ho mai compreso il concetto completo di queste directory.

Cosa vogliono dire?

Answer 1

Hmm, non sono sicuro di essere d'accordo con il fatto che il tag Nick sia simile a un ramo.Un tag è solo un indicatore

• Tronco sarebbe il corpo principale dello sviluppo, originato dall'inizio del progetto fino ad oggi.

• Ramo sarà una copia del codice derivato da un certo punto nel trunk che viene utilizzato per applicare modifiche importanti al codice preservando l'integrità del codice nel trunk.Se le modifiche principali funzionano secondo i piani, di solito vengono reintegrate nel bagagliaio.

• Etichetta sarà un punto nel tempo sul tronco o su un ramo che desideri preservare.Le due ragioni principali per la conservazione sarebbero che questa è una versione principale del software, sia alfa, beta, RC o RTM, oppure questo è il punto più stabile del software prima che venissero applicate le revisioni principali sul trunk.

Nei progetti open source, i rami principali che non sono accettati nel trunk dalle parti interessate del progetto possono diventare le basi per forchette -- Ad esempio, progetti totalmente separati che condividono un'origine comune con altro codice sorgente.

I sottoalberi ramo e tag si distinguono dal tronco nei seguenti modi:

Subversion consente agli amministratori di sistema di creare script di hook che vengono attivati ​​per l'esecuzione quando si verificano determinati eventi;ad esempio, confermando una modifica al repository.È molto comune per una tipica implementazione del repository Subversion trattare qualsiasi percorso contenente "/tag/" come protetto da scrittura dopo la creazione;il risultato netto è che i tag, una volta creati, sono immutabili (almeno per gli utenti "ordinari").Ciò avviene tramite gli script hook, che rafforzano l'immutabilità impedendo ulteriori modifiche if etichetta è un nodo genitore dell'oggetto modificato.

Subversion ha anche aggiunto funzionalità, a partire dalla versione 1.5, relative al "tracciamento della fusione dei rami" in modo che le modifiche apportate a un ramo può essere riunito nuovamente nel trunk con il supporto per l'unione incrementale e "intelligente".

Answer 2

Prima di tutto, come sottolineano @AndrewFinnell e @KenLiu, in SVN i nomi delle directory stessi non significano nulla: "tronco, rami e tag" sono semplicemente una convenzione comune utilizzata dalla maggior parte dei repository.Non tutti i progetti utilizzano tutte le directory (è ragionevolmente comune non utilizzare affatto i "tag") e, in effetti, nulla ti impedisce di chiamarli come preferisci, anche se infrangere le convenzioni spesso crea confusione.

Descriverò probabilmente lo scenario di utilizzo più comune di rami e tag e fornirò uno scenario di esempio di come vengono utilizzati.

• Tronco:La principale area di sviluppo.Qui è dove risiede la prossima versione principale del codice e generalmente contiene tutte le funzionalità più recenti.

• Rami:Ogni volta che rilasci una versione principale, viene creato un ramo.Ciò consente di correggere i bug e creare una nuova versione senza dover rilasciare le funzionalità più recenti, possibilmente incomplete o non testate.

• Tag:Ogni volta che rilasci una versione (versione finale, release candidate (RC) e beta) crei un tag per essa.Questo ti dà una copia puntuale del codice così com'era in quello stato, permettendoti di tornare indietro e riprodurre eventuali bug, se necessario, in una versione precedente, o rilasciare nuovamente una versione precedente esattamente com'era.I rami e i tag in SVN sono leggeri: sul server non viene creata una copia completa dei file, solo un indicatore che dice "questi file sono stati copiati in questa revisione" che occupa solo pochi byte.Con questo in mente, non dovresti mai preoccuparti di creare un tag per qualsiasi codice rilasciato.Come ho detto prima, i tag vengono spesso omessi e invece un registro delle modifiche o un altro documento chiarisce il numero di revisione quando viene effettuato un rilascio.

---

Ad esempio, supponiamo che tu inizi un nuovo progetto.Si inizia a lavorare in “trunk”, su quella che eventualmente verrà rilasciata come versione 1.0.

• trunk/ - versione di sviluppo, presto sarà la 1.0
• rami/ - vuoto

Una volta terminata la versione 1.0.0, dirama il trunk in un nuovo ramo "1.0" e crea un tag "1.0.0".Ora il lavoro su quello che alla fine sarà la 1.1 continua nel trunk.

• trunk/ - versione di sviluppo, presto sarà 1.1
• branch/1.0 - versione di rilascio 1.0.0
• tags/1.0.0 - versione di rilascio 1.0.0

Ti imbatti in alcuni bug nel codice e li risolvi nel trunk, quindi unisci le correzioni nel ramo 1.0.Puoi anche fare il contrario e correggere i bug nel ramo 1.0 e poi unirli nuovamente nel trunk, ma comunemente i progetti si attengono all'unione unidirezionale solo per ridurre la possibilità di perdere qualcosa.A volte un bug può essere corretto solo nella versione 1.0 perché è obsoleto nella versione 1.1.Non ha molta importanza:vuoi solo assicurarti di non rilasciare la versione 1.1 con gli stessi bug che sono stati corretti nella versione 1.0.

• trunk/ - versione di sviluppo, presto sarà la 1.1
• rami/1.0 - prossima versione 1.0.1
• tags/1.0.0 - versione di rilascio 1.0.0

Una volta trovati abbastanza bug (o forse un bug critico), decidi di fare una versione 1.0.1.Quindi crei un tag "1.0.1" dal ramo 1.0 e rilasci il codice.A questo punto, il trunk conterrà quello che sarà 1.1 e il ramo "1.0" conterrà il codice 1.0.1.La prossima volta che rilasci un aggiornamento alla 1.0, sarà 1.0.2.

• trunk/ - versione di sviluppo, presto sarà la 1.1
• rami/1.0 - prossima versione 1.0.2
• tags/1.0.0 - versione di rilascio 1.0.0
• tags/1.0.1 - Versione di rilascio 1.0.1

Alla fine sarai quasi pronto per rilasciare la versione 1.1, ma prima vuoi fare una beta.In questo caso, probabilmente eseguirai un ramo "1.1" e un tag "1.1beta1".Ora, il lavoro su quello che sarà 1.2 (o forse 2.0) continua nel trunk, ma il lavoro su 1.1 continua nel ramo "1.1".

• trunk/ - versione di sviluppo, presto sarà 1.2
• branchs/1.0 - prossima versione 1.0.2
• branchs/1.1 - prossima versione 1.1.0
• tags/1.0.0 - versione di rilascio 1.0.0
• tags/1.0.1 - Versione di rilascio 1.0.1
• tags/1.1beta1 - versione di rilascio 1.1 beta 1

Una volta rilasciata la versione 1.1 finale, si crea un tag "1.1" dal ramo "1.1".

Puoi anche continuare a mantenere la versione 1.0, se lo desideri, trasferendo le correzioni di bug tra tutti e tre i rami (1.0, 1.1 e trunk).La conclusione importante è che per ogni versione principale del software che stai mantenendo, hai un ramo che contiene l'ultima versione del codice per quella versione.

---

Un altro uso dei rami è per le funzionalità.Qui è dove si dirama il trunk (o uno dei rami di rilascio) e si lavora su una nuova funzionalità in isolamento.Una volta completata la funzionalità, uniscila nuovamente e rimuovi il ramo.

• trunk/ - versione di sviluppo, presto sarà la 1.2
• branchs/1.1 - prossima versione 1.1.0
• branch/ui-rewrite - ramo di funzionalità sperimentale

L'idea di questo è quando stai lavorando su qualcosa di dirompente (che ostacolerebbe o interferirebbe con lo svolgimento del lavoro di altre persone), qualcosa di sperimentale (che potrebbe anche non farcela), o forse semplicemente qualcosa che richiede molto tempo (e hai paura se trattiene una versione 1.2 quando sei pronto per eseguire il branch 1.2 dal trunk), puoi farlo isolatamente nel branch.Generalmente lo mantieni aggiornato con il trunk unendo continuamente le modifiche, il che rende più semplice la reintegrazione (unisci nuovamente al trunk) quando hai finito.

---

Tieni inoltre presente che lo schema di controllo delle versioni che ho utilizzato qui è solo uno dei tanti.Alcuni team eseguirebbero rilasci di correzione/manutenzione come 1.1, 1.2, ecc. e modifiche importanti come 1.x, 2.x, ecc.L'utilizzo qui è lo stesso, ma puoi nominare il ramo "1" o "1.x" invece di "1.0" o "1.0.x".(A parte, versione semantica è una buona guida su come creare i numeri di versione).

Answer 3

Oltre a ciò che ha detto Nick, puoi saperne di più su Linee in streaming:Modelli di ramificazione per lo sviluppo di software parallelo

In questa figura main è il bagagliaio, rel1-maint è un ramo e 1.0 è un'etichetta.

Answer 4

Generalmente (vista indipendente dallo strumento), un ramo è il meccanismo utilizzato per lo sviluppo parallelo.Un SCM può avere da 0 a n rami.Subversion ha 0.

• Tronco è un ramo principale consigliato da Sovversione, ma non sei in alcun modo obbligato a crearlo.Potresti chiamarlo "principale" o "release", o non averne affatto uno!

• Ramo rappresenta uno sforzo di sviluppo.Non dovrebbe mai prendere il nome da una risorsa (come 'vonc_branch') ma da:

  • uno scopo 'myProject_dev' o 'myProject_Merge'
  • un perimetro di rilascio 'myProjetc1.0_dev'o myProject2.3_Merge' o 'myProject6..2_Patch1'...

• Etichetta è un'istantanea dei file per tornare facilmente a quello stato.Il problema è che tag e ramo sono gli stessi in Subversion.E consiglierei sicuramente l'approccio paranoico:

  puoi utilizzare uno degli script di controllo dell'accesso forniti con Subversion per impedire a chiunque di fare altro che creare nuove copie nell'area dei tag.

Un tag è definitivo.Il suo contenuto non dovrebbe mai cambiare.MAI.Mai.Hai dimenticato una riga nella nota di rilascio?Crea una nuova etichetta.Obsoleto o rimuovi quello vecchio.

Ora, ho letto molto sul "riunire questo e quest'altro in questo e quest'altro ramo, e infine nel ramo del tronco".Così si chiama unire il flusso di lavoro e c'è niente di obbligatorio qui.Non è perché hai un ramo del tronco che tu devono fondersi di nuovo nulla.

Per convenzione il ramo del tronco può rappresentare lo stato attuale del vostro sviluppo, ma si tratta di un semplice progetto sequenziale, cioè un progetto che ha:

• nessuno sviluppo "in anticipo" (per la preparazione della versione successiva che implica modifiche tali da non essere compatibili con l'attuale sviluppo "trunk")
• nessun refactoring massiccio (per testare una nuova scelta tecnica)
• nessuna manutenzione a lungo termine di una versione precedente

Perché con uno (o tutti) questi scenari, ottieni quattro "tronchi", quattro "sviluppi attuali" e non tutto ciò che fai in quegli sviluppi paralleli dovrà necessariamente essere riunito nel "tronco".

Answer 5

In SVN un tag e un ramo sono molto simili.

Etichetta = una porzione di tempo definita, solitamente utilizzata per i rilasci

Ramo = anche una porzione di tempo definita su cui lo sviluppo può continuare, solitamente utilizzata per la versione principale come 1.0, 1.5, 2.0, ecc., quindi quando rilasci tagghi il ramo.Ciò ti consente di continuare a supportare una versione di produzione mentre procedi con modifiche importanti nel trunk

Tronco = spazio di lavoro di sviluppo, è qui che dovrebbe avvenire tutto lo sviluppo e quindi le modifiche riunite dai rilasci dei rami.

Answer 6

In realtà non hanno alcun significato formale.Una cartella è una cartella per SVN.Sono un modo generalmente accettato per organizzare il tuo progetto.

• Il tronco è dove mantieni la tua linea principale di sviluppo.La cartella dei rami è dove potresti creare, beh, rami, che sono difficili da spiegare in un breve post.

• Un ramo è una copia di un sottoinsieme del tuo progetto su cui lavori separatamente dal tronco.Forse è per esperimenti che potrebbero non portare da nessuna parte, o forse è per la prossima versione, che in seguito unirai nuovamente al trunk quando diventerà stabile.

• E la cartella dei tag serve per creare copie taggate del tuo repository, solitamente ai checkpoint di rilascio.

Ma come ho detto, per SVN, una cartella è una cartella. branch, trunk e tag sono solo una convenzione.

Sto usando la parola "copia" liberamente.SVN in realtà non crea copie complete delle cose nel repository.

Answer 7

IL tronco è la linea di sviluppo che contiene il codice sorgente e le funzionalità più recenti.Dovrebbe contenere le ultime correzioni di bug e le ultime funzionalità aggiunte al progetto.

IL rami vengono solitamente utilizzati per fare qualcosa lontano dal trunk (o da un'altra linea di sviluppo) che altrimenti verrebbe rottura la costruzione.Le nuove funzionalità vengono spesso integrate in un ramo e poi riunite nuovamente nel tronco.I rami spesso contengono codice che non è necessariamente approvato per la linea di sviluppo da cui si è ramificato.Ad esempio, un programmatore potrebbe provare un'ottimizzazione su qualcosa in un ramo e rientrare nella linea di sviluppo solo quando l'ottimizzazione è soddisfacente.

IL tag sono istantanee del repository in un momento particolare.Su questi non dovrebbe verificarsi alcuno sviluppo.Vengono spesso utilizzati per eseguire una copia di ciò che è stato rilasciato a un client in modo da poter accedere facilmente a ciò che sta utilizzando un client.

Ecco un collegamento a un'ottima guida ai repository:

• Manuale sul controllo del codice sorgente

Vale la pena leggere anche gli articoli di Wikipedia.

Answer 8

Questo è il problema dello sviluppo software: non c'è una conoscenza coerente su nulla, ognuno sembra fare a modo suo, ma è perché è comunque una disciplina relativamente giovane.

Ecco il mio modo semplice e semplice,

tronco - La directory trunk contiene il corpo di lavoro più aggiornato, approvato e unificato.Contrariamente a quanto molti hanno confessato, il mio bagagliaio è solo per lavori puliti, ordinati e approvati e non è un'area di sviluppo, ma piuttosto un'area di rilascio.

Ad un certo punto nel tempo, quando il bagagliaio sembra pronto per essere rilasciato, viene contrassegnato e rilasciato.

rami - La directory dei rami contiene esperimenti e lavori in corso.Il lavoro sotto un ramo rimane lì finché non viene approvato per essere unito al tronco.Per me, questa è l’area in cui viene svolto tutto il lavoro.

Per esempio:Posso avere un iterazione-5 ramo per un quinto round di sviluppo del prodotto, forse a prototipo-9 ramificarsi per un nono ciclo di esperimenti e così via.

tag - La directory dei tag contiene istantanee dei rami approvati e delle versioni del trunk.Ogni volta che viene approvata l'unione di un ramo nel trunk o viene creato un rilascio del trunk, viene creata un'istantanea del ramo o del rilascio del trunk approvato sotto i tag.

Suppongo che con i tag posso saltare avanti e indietro nel tempo per raggiungere i punti di interesse abbastanza facilmente.

Answer 9

Ho trovato questo fantastico tutorial riguardante SVN mentre stavo cercando il sito web di autore del OpenCV 2 Ricettario per la programmazione di applicazioni di visione artificiale e ho pensato di condividerlo.

Ha un tutorial su come usare SVN e cosa significano le frasi "trunk", "tag" e "branch".

Citato direttamente dal suo tutorial:

La versione attuale del tuo progetto software, su cui sta attualmente lavorando il tuo team, si trova solitamente in una directory chiamata tronco.Man mano che il progetto si evolve, lo sviluppatore aggiorna quella versione (corregge bug, aggiunge nuove funzionalità) e invia le sue modifiche in quella directory.

In qualsiasi momento, potresti voler bloccare una versione e acquisire un'istantanea del software così com'è in questa fase dello sviluppo.Generalmente corrisponde alle versioni ufficiali del tuo software, ad esempio quelle che consegnerai ai tuoi clienti.Queste istantanee si trovano sotto il file tag directory del tuo progetto.

Infine, spesso è utile creare, ad un certo punto, una nuova linea di sviluppo per il proprio software.Questo accade, ad esempio, quando desideri testare un'implementazione alternativa in cui devi modificare il tuo software ma non vuoi sottoporre queste modifiche al progetto principale finché non decidi se adottare la nuova soluzione.Il team principale può quindi continuare a lavorare sul progetto mentre gli altri sviluppatori lavorano sul prototipo.Metteresti queste nuove linee di sviluppo del progetto in una directory chiamata rami.

Answer 10

La directory trunk è la directory con cui probabilmente hai più familiarità, perché viene utilizzata per contenere le modifiche più recenti.La tua codebase principale dovrebbe essere nel trunk.

La directory branch serve a contenere i tuoi rami, qualunque essi siano.

La directory dei tag serve fondamentalmente per contrassegnare un determinato insieme di file.Lo fai per cose come le versioni, dove vuoi che "1.0" siano questi file a queste revisioni e "1.1" siano questi file a queste revisioni.Di solito non modifichi i tag una volta creati.Per ulteriori informazioni sui tag, vedere Capitolo 4.Ramificazione e fusione (In Controllo della versione con Subversion).

Answer 11

Uno dei motivi per cui ognuno ha una definizione leggermente diversa è perché Subversion implementa zero supporto per rami e tag.Subversion sostanzialmente dice: Abbiamo guardato completo di funzionalità branch e tag in altri sistemi e non li abbiamo trovati utili, quindi non abbiamo implementato nulla.Basta crearne una copia in una nuova directory con un nome convenzione Invece.Poi ovviamente ognuno è libero di avere convenzioni leggermente diverse.Per comprendere la differenza tra a vero Tag e una semplice copia + Convenzione di denominazione Vedi la voce di Wikipedia Tag e rami di sovversione.

Answer 12

Tag = una porzione di tempo definita, solitamente utilizzata per i rilasci

Penso che questo sia ciò che in genere si intende per "tag".Ma in Subversion:

In realtà non hanno alcun significato formale.Una cartella è una cartella per SVN.

che trovo piuttosto confuso:un sistema di controllo di revisione che non sa nulla di rami o tag.Da un punto di vista dell'implementazione, penso che il modo in cui Subversion crea "copie" sia molto intelligente, ma doverlo sapere è quello che definirei un astrazione che perde.

O forse lo sto semplicemente usando CVS troppo tempo.

Answer 13

Penso che parte della confusione derivi dalla differenza tra il concetto di tag e l'implementazione in SVN.Per SVN un tag è un ramo che è una copia.La modifica dei tag è considerata sbagliata e infatti strumenti come TortoiseSVN ti avviseranno se tenti di modificare qualcosa con ../tags/..nel percorso.

Answer 14

Non sono proprio sicuro di cosa sia "tag", ma branch è un concetto di controllo del codice sorgente abbastanza comune.

Fondamentalmente, un ramo è un modo per lavorare sulle modifiche al codice senza influenzare il tronco.Supponiamo che tu voglia aggiungere una nuova funzionalità abbastanza complicata.Vuoi essere in grado di archiviare le modifiche mentre le apporti, ma non vuoi che influiscano sul trunk finché non hai finito con la funzione.

Per prima cosa creerai un ramo.Questa è fondamentalmente una copia del tronco nel momento in cui hai creato il ramo.Quindi faresti tutto il tuo lavoro nella filiale.Qualsiasi modifica apportata nel ramo non influisce sul tronco, quindi il tronco è ancora utilizzabile, consentendo ad altri di continuare a lavorare lì (come apportare correzioni di bug o piccoli miglioramenti).Una volta completata la funzionalità, integrerai nuovamente il ramo nel trunk.Ciò sposterebbe tutte le modifiche dal ramo al tronco.

Esistono numerosi modelli che le persone utilizzano per i rami.Se disponi di un prodotto con più versioni principali supportate contemporaneamente, in genere ciascuna versione sarà un ramo.Dove lavoro abbiamo una filiale QA e una filiale Produzione.Prima di rilasciare il nostro codice al QA integriamo le modifiche al ramo QA, quindi le distribuiamo da lì.Quando rilasciamo in produzione integriamo dal ramo QA al ramo Produzione, quindi sappiamo che il codice in esecuzione in produzione è identico a quello testato dal QA.

Ecco il Voce di Wikipedia sui rami, dal momento che probabilmente spiegano le cose meglio di me.:)

Answer 15

Per chi ha familiarità con GIT, master in GIT equivale a trunk in SVN.

Il ramo e il tag hanno la stessa terminologia sia in GIT che in SVN.

Answer 16

Tronco :Dopo il completamento di ogni sprint in agile otteniamo un prodotto parzialmente spedibile.Queste versioni vengono conservate nel bagagliaio.

Rami :Tutti i codici di sviluppo parallelo per ogni sprint in corso sono conservati nei rami.

Tag :Ogni volta che rilasciamo una versione beta di un prodotto parzialmente spedibile, creiamo un tag per esso.Questo ci fornisce il codice che era disponibile in quel momento, permettendoci di tornare a quello stato se richiesto ad un certo punto durante lo sviluppo.