Che cosa significano "branch", "tag" e "trunk" nei repository Subversion?

Ho visto queste parole molto intorno alle discussioni di Subversion (e immagino un repository generale).
Ho usato SVN per i miei progetti negli ultimi anni, ma non ho mai capito il concetto completo di queste directory.

Cosa vogliono dire?

Hmm, non sono sicuro di essere d'accordo sul fatto che Nick Re Tag sia simile a un ramo. Un tag è solo un marker

• Trunk sarebbe il principale corpo di sviluppo, originando dall'inizio del progetto fino ad oggi.

• Branch sarà una copia del codice derivata da un certo punto nel trunk che viene utilizzata per applicare le modifiche principali al codice preservando l'integrità del codice nel trunk. Se le modifiche principali funzionano in base al piano, di solito vengono nuovamente riunite nel trunk.

• L'etichetta sarà un punto nel tempo sul tronco o su un ramo che desideri conservare. Le due ragioni principali per la conservazione sarebbero che questa è una delle principali versioni del software, sia essa alfa, beta, RC o RTM, o questo è il punto più stabile del software prima che vengano applicate le principali revisioni sul bagagliaio.

Nei progetti open source, le principali filiali che non sono accettate nel bagagliaio dalle parti interessate del progetto possono diventare le basi per le forcelle , ad esempio progetti totalmente separati che condividono un'origine comune con altri codici sorgente.

Le succursali branch e tag si distinguono dal trunk nei seguenti modi:

Subversion consente agli amministratori di sistema di creare script hook che vengono attivati ​​per l'esecuzione quando si verificano determinati eventi; ad esempio, eseguendo una modifica al repository. È molto comune per una tipica implementazione di repository Subversion trattare qualsiasi percorso contenente "/ tag /" da proteggere 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 impongono l'immutabilità impedendo ulteriori modifiche se il tag è un nodo padre dell'oggetto modificato.

Subversion ha anche aggiunto funzionalità, a partire dalla versione 1.5, relative al "monitoraggio della fusione di diramazioni" in modo che le modifiche impegnate in un ramo possano essere ricondotte nel trunk con il supporto per l'unione incrementale "intelligente".

Innanzitutto, come sottolineato da @AndrewFinnell e @KenLiu, in SVN i nomi delle directory stesse non significano nulla: "trunk, rami e tag" sono semplicemente una convenzione comune utilizzata dalla maggior parte dei repository. Non tutti i progetti usano tutte le directory (è abbastanza comune non usare affatto i "tag"), e in effetti nulla ti impedisce di chiamarli come preferisci, sebbene infrangere le convenzioni sia spesso fonte di confusione.

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

• Trunk : la principale area di sviluppo. È qui che risiede la tua prossima versione principale del codice e in genere ha tutte le funzionalità più recenti.

• Filiali : ogni volta che rilasci una versione principale, viene creato un ramo. Ciò consente di eseguire correzioni di errori e di effettuare una nuova versione senza dover rilasciare le funzionalità più recenti, probabilmente non finite o non testate.

• Tag : ogni volta che rilasci una versione (release finale, release candidate (RC) e beta) crei un tag per essa. Questo ti dà una copia temporizzata del codice com'era in quello stato, permettendoti di tornare indietro e riprodurre eventuali bug se necessario in una versione passata, o rilasciare nuovamente una versione passata esattamente com'era. I rami e i tag in SVN sono leggeri: sul server non crea una copia completa dei file, ma solo un marcatore 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 log delle modifiche o un altro documento chiarisce il numero di revisione quando viene effettuata una versione.

Ad esempio, supponiamo che inizi un nuovo progetto. Inizi a lavorare in "trunk", su ciò che alla fine verrà rilasciato come versione 1.0.

• trunk / - versione di sviluppo, che presto sarà 1.0
• rami / - vuoti

Al termine della 1.0.0, si dirama il ramo in un nuovo ramo "1.0" e si crea un tag "1.0.0". Ora il lavoro su quello che alla fine sarà 1.1 continua nel bagagliaio.

• trunk / - versione di sviluppo, presto sarà 1.1
• rami / 1.0 - 1.0.0 versione di rilascio
• tag / 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 al ramo 1.0. Puoi anche fare il contrario e correggere i bug nel ramo 1.0 e poi fonderli nuovamente nel trunk, ma comunemente i progetti si attaccano alla fusione unidirezionale solo per ridurre la possibilità di perdere qualcosa. A volte un bug può essere corretto solo in 1.0 perché è obsoleto in 1.1. Non importa: vuoi solo assicurarti di non rilasciare 1.1 con gli stessi bug che sono stati corretti in 1.0.

• trunk / - versione di sviluppo, presto sarà 1.1
• filiali / 1.0 - prossima versione 1.0.1
• tag / 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 si crea un tag "1.0.1" dal ramo 1.0 e si rilascia il codice. A questo punto, il trunk conterrà quello che sarà 1.1 e il ramo "1.0" contiene il codice 1.0.1. La prossima volta che rilasci un aggiornamento a 1.0, sarà 1.0.2.

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

Alla fine sei quasi pronto per rilasciare la versione 1.1, ma prima vuoi fare una beta. In questo caso, è probabile che tu faccia 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
• filiali / 1.0 - prossima versione 1.0.2
• filiali / 1.1 - prossima versione 1.1.0
• tag / 1.0.0 - Versione di rilascio 1.0.0
• tags / 1.0.1 - Versione di rilascio 1.0.1
• tags / 1.1beta1 - 1.1 beta 1 versione di rilascio

Dopo aver rilasciato 1.1 final, fai un tag "1.1" dal ramo "1.1".

Se lo desideri, puoi anche continuare a mantenere 1.0, porting delle correzioni di bug tra tutti e tre i rami (1.0, 1.1 e trunk). L'importante da asporto è che per ogni versione principale del software che si sta mantenendo, si dispone di un ramo che contiene l'ultima versione del codice per quella versione.

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

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

L'idea è quando stai lavorando a qualcosa di dirompente (che potrebbe reggere o interferire con altre persone dal fare il loro lavoro), qualcosa di sperimentale (che potrebbe anche non farcela), o forse solo qualcosa che richiede molto tempo (e hai paura se tiene una versione 1.2 quando sei pronto per il ramo 1.2 dal tronco), puoi farlo da solo nel ramo. Generalmente tieniti aggiornato con trunk unendo continuamente le modifiche in esso, il che rende più facile reintegrare (unire nuovamente a trunk) al termine.

Inoltre, lo schema di versione che ho usato qui è solo uno dei tanti. Alcuni team eseguono correzioni di bug / versioni di manutenzione come 1.1, 1.2, ecc. E modifiche importanti come 1.x, 2.x, ecc. L'uso qui è lo stesso, ma è possibile nominare il ramo "1" o "1 .x "anziché" 1.0 "o" 1.0.x ". (A parte, il controllo delle versioni semantico è una buona guida su come eseguire i numeri di versione).

Oltre a quanto affermato da Nick, puoi trovare ulteriori informazioni su Streamed Lines: Branching Patterns for Parallel Software Development

In questa figura mainè il tronco, rel1-maintè un ramo ed 1.0è un tag.

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

• Trunk è un ramo principale consigliato da Subversion , ma non sei in alcun modo costretto a crearlo. Potresti chiamarlo "principale" o "rilasci", o non averne affatto uno!

• Branch rappresenta uno sforzo di sviluppo. Non dovrebbe mai essere chiamato dopo una risorsa (come 'vonc_branch') ma dopo:

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

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

  è possibile utilizzare uno degli script di controllo degli accessi forniti con Subversion per impedire a chiunque di fare qualsiasi cosa tranne creare nuove copie nell'area dei tag.

Un tag è finale. Il suo contenuto non dovrebbe mai cambiare. MAI. Mai. Hai dimenticato una riga nella nota di rilascio? Crea un nuovo tag. Obsoleto o rimuovere quello vecchio.

Ora, ho letto molto su "fondere tali e tali in tali e tali rami, poi infine nel ramo del tronco". Questo è chiamato flusso di lavoro di unione e qui non c'è nulla di obbligatorio . Non è perché hai un ramo di tronco che devi fondere qualcosa di nuovo .

Per convenzione, il ramo del tronco può rappresentare lo stato attuale del tuo sviluppo, ma questo è per un semplice progetto sequenziale, cioè un progetto che ha:

• nessuno sviluppo "in anticipo" (per la preparazione della prossima versione successiva che implica cambiamenti 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) di quegli scenari, ottieni quattro "tronchi", quattro "sviluppi attuali" e non tutto ciò che fai in quegli sviluppi paralleli dovrà necessariamente essere ricondotto in "tronco".

In SVN un tag e un ramo sono molto simili.

Tag = una sezione definita nel tempo, generalmente utilizzata per le versioni

Branch = anche una porzione definita nel tempo in cui lo sviluppo può continuare, solitamente utilizzato per le versioni principali come 1.0, 1.5, 2.0, ecc., Quindi quando rilasci tagghi il ramo. Ciò consente di continuare a supportare un rilascio di produzione mentre si procede in avanti con interruzioni nel bagagliaio

Trunk = spazio di lavoro di sviluppo, qui è dove dovrebbe avvenire tutto lo sviluppo e quindi le modifiche si fondono con le versioni di filiale.

Non hanno davvero alcun significato formale. Una cartella è una cartella in SVN. Sono un modo generalmente accettato per organizzare il tuo progetto.

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

• Un ramo è una copia di un sottoinsieme del progetto su cui lavori separatamente dal tronco. Forse è per esperimenti che potrebbero non andare da nessuna parte, o forse è per la prossima versione, che successivamente ti ricollegherai nel bagagliaio quando diventa 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, trunkE tag sono solo una convenzione.

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

Il trunk è 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.

I rami sono solitamente usati per fare qualcosa lontano dal tronco (o altra linea di sviluppo) che altrimenti spezzerebbe la build. Le nuove funzionalità sono spesso integrate in un ramo e quindi riunite nuovamente nel trunk. Le filiali spesso contengono codice che non è necessariamente approvato per la linea di sviluppo da cui si è ramificata. Ad esempio, un programmatore potrebbe provare un'ottimizzazione su qualcosa in un ramo e rientrare nella linea di sviluppo solo quando l'ottimizzazione è soddisfacente.

I tag sono istantanee del repository in un determinato momento. Nessuno sviluppo dovrebbe verificarsi su questi. Sono spesso usati per prendere una copia di ciò che è stato rilasciato a un client in modo da poter avere facilmente accesso a ciò che un client sta usando.

Ecco un link a un'ottima guida ai repository:

• HOWTO sul controllo del codice sorgente

Vale la pena leggere anche gli articoli di Wikipedia.

Ora questo è lo sviluppo del software, non c'è una conoscenza coerente di nulla, tutti sembrano averlo a modo loro, ma è perché è comunque una disciplina relativamente giovane.

Ecco il mio semplice modo semplice,

trunk : la directory trunk contiene il corpo di lavoro più aggiornato, approvato e unito. Contrariamente a quanto molti hanno confessato, il mio baule è solo per lavoro pulito, ordinato, approvato e non un'area di sviluppo, ma piuttosto un'area di rilascio.

In un determinato momento, quando il trunk sembra pronto per essere rilasciato, viene taggato e rilasciato.

rami : la directory rami contiene esperimenti e lavori in corso. Il lavoro sotto un ramo rimane lì fino a quando non viene approvato per essere unito nel bagagliaio. Per me, questa è l'area in cui tutto il lavoro è svolto.

Ad esempio: posso avere un ramo iterazione-5 per un quinto round di sviluppo sul prodotto, forse un ramo prototipo-9 per un nono round di sperimentazione, e così via.

tags : la directory tags contiene snapshot di filiali e versioni di trunk approvate. Ogni volta che un ramo viene approvato per fondersi nel tronco o viene rilasciato un rilascio del tronco, un'istantanea del ramo approvato o rilascio del tronco viene effettuata sotto i tag.

Suppongo che con i tag posso saltare avanti e indietro nel tempo per evidenziare abbastanza facilmente l'interesse dei punti.

Ho trovato questo fantastico tutorial su SVN mentre cercavo il sito web dell'autore del ricettario di programmazione per applicazioni di visione artificiale OpenCV 2 e ho pensato di condividere.

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

Citato direttamente dal suo tutorial:

La versione corrente del tuo progetto software, su cui sta attualmente lavorando il tuo team, si trova di solito in una directory chiamata trunk . Man mano che il progetto si evolve, lo sviluppatore aggiorna la versione per correggere i bug, aggiungere nuove funzionalità) e inviare 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. Ciò corrisponde generalmente alle versioni ufficiali del software, ad esempio quelle che consegnerai ai tuoi clienti. Queste istantanee si trovano nella directory dei tag del progetto.

Infine, è spesso utile creare, a un certo punto, una nuova linea di sviluppo per il tuo software. Ciò accade, ad esempio, quando si desidera testare un'implementazione alternativa in cui è necessario modificare il software ma non si desidera inviare queste modifiche al progetto principale fino a quando non si decide se adottare la nuova soluzione. Il team principale può quindi continuare a lavorare sul progetto mentre altri sviluppatori lavorano sul prototipo. Inseriresti queste nuove linee di sviluppo del progetto in una directory chiamata rami .

La directory trunk è la directory che probabilmente hai più familiarità, poiché viene utilizzata per contenere le modifiche più recenti. Il tuo codebase principale dovrebbe essere nel trunk.

La directory rami è per contenere i tuoi rami, qualunque essi siano.

La directory dei tag serve essenzialmente per taggare un determinato set di file. Lo fai per cose come i rilasci, dove vuoi che "1.0" sia questi file in queste revisioni e "1.1" sia questi file in queste revisioni. Di solito non modifichi i tag una volta creati. Per ulteriori informazioni sui tag, consultare il Capitolo 4. Diramazione e unione (in Controllo versione con Subversion ).

Uno dei motivi per cui ognuno ha una definizione leggermente diversa è perché Subversion implementa il supporto zero per filiali e tag. Subversion dice in sostanza: abbiamo esaminato rami e tag con funzionalità complete in altri sistemi e non li abbiamo trovati utili, quindi non abbiamo implementato nulla. Basta fare una copia in una nuova directory con una convenzione di nome invece . Quindi ovviamente tutti sono liberi di avere convenzioni leggermente diverse. Per comprendere la differenza tra un tag reale e una semplice convenzione di copia + denominazione, vedere la voce Wikipedia Tag e rami di Subversion .

Tag = una sezione definita nel tempo, generalmente utilizzata per le versioni

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

Non hanno davvero alcun significato formale. Una cartella è una cartella in SVN.

che trovo piuttosto confuso: un sistema di controllo delle revisioni che non sa nulla di rami o tag. Da un punto di vista dell'implementazione, penso che il modo Subversion di creare "copie" sia molto intelligente, ma il fatto che io debba saperlo è ciò che definirei un'astrazione che perde .

O forse sto usando CVS da troppo tempo.

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 errata e in effetti strumenti come TortoiseSVN ti avviseranno se tenti di modificare qualcosa con ../tags/ .. nel percorso.

Non sono davvero 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 influire sul trunk. Supponi di voler aggiungere una nuova funzionalità piuttosto complicata. Vuoi essere in grado di controllare le modifiche mentre le apporti, ma non vuoi che influisca sul trunk fino a quando non hai finito con la funzione.

Per prima cosa crei un ramo. Questa è fondamentalmente una copia del trunk a partire dal momento in cui hai creato il ramo. Faresti quindi tutto il tuo lavoro nel ramo. Tutte le modifiche apportate nel ramo non influiscono sul trunk, quindi il trunk è ancora utilizzabile, consentendo ad altri di continuare a lavorare lì (come fare correzioni di bug o piccoli miglioramenti). Una volta terminata la funzionalità, il ramo verrà reintegrato nel trunk. Ciò sposterebbe tutte le modifiche dal ramo al tronco.

Esistono numerosi modelli che le persone usano per i rami. Se si dispone di un prodotto con più versioni principali supportate contemporaneamente, in genere ogni versione sarebbe un ramo. Dove lavoro, abbiamo una filiale di controllo qualità e una filiale di produzione. Prima di rilasciare il nostro codice al QA integriamo le modifiche al ramo QA, quindi distribuiamo da lì. Quando si rilascia alla produzione, ci integriamo dal ramo QA al ramo Produzione, quindi sappiamo che il codice in esecuzione nella produzione è identico a quello testato dal QA.

Ecco la voce di Wikipedia sui rami , poiché probabilmente spiegano le cose meglio di me. :)

Tronco : dopo il completamento di ogni sprint in agile usciamo con un prodotto parzialmente spedibile. Queste versioni sono conservate nel bagagliaio.

Branch : tutti i codici di sviluppo paralleli per ogni sprint in corso sono mantenuti in branch.

Tag : ogni volta che viene rilasciato un tipo di prodotto in versione parzialmente beta della versione beta, creiamo un tag per questo. Questo ci dà il codice che era disponibile in quel momento, permettendoci di tornare a quello stato se richiesto ad un certo punto durante lo sviluppo.

Per le persone che hanno familiarità con GIT, il master in GIT equivale al trunk in SVN.

Branch e tag hanno la stessa terminologia sia in GIT che in SVN.