Usa Subversion Without Trunk

Question

Il mio team ha recentemente deciso di non utilizzare il ramo "trunk" che è tipico della maggior parte dei layout di repository di subversion. Abbiamo scoperto che in ogni momento c'era sempre un ramo particolare che funzionava nel ruolo tradizionale che il tronco avrebbe avuto in altri repository. Cioè, abbiamo sempre un ramo con il numero più alto che rappresenta la prossima versione su cui stiamo lavorando. Quindi unire il tronco è semplicemente superfluo, quindi ci siamo sbarazzati del tronco.

Qualcun altro là fuori lo fa?

Se sì, hai notato qualche pro/contro?

Anche se la tua squadra non lo fa, qualcuno ha qualche idea su questo layout?

Answer 1

Stai parlando del Promotional Model - Il documento di Perforce ne mette in evidenza i problemi: comunicare i ruoli mutevoli delle code line e spostare il lavoro tra le filiali.

Un'espansione sulle mie opinioni dei problemi elencati:

1) Modifica politica di code-lines:

Ogni linea di codice ha una politica, che si tratti di scritto e formalizzato, o interamente implicita in un la testa dello sviluppatore Definisce es:

• chi è autorizzato ad impegnarsi al codice linea
• quanti test è richiesto (ad esempio fare l'unità test devono passare, test di regressione, test completo del sistema)
• quante persone hanno a che la revisione del codice cambia
• che tipo di cambiamenti sono ammessi

Con l'approccio trunk, le policy rimangono fisse, quindi sono più facili da annotare, il che rende più facile la comunicazione (più importante in un team più grande).

ad es.Tronco:

• qualsiasi sviluppatore può commettere
• alcun cambiamento
• unit test devono passare
• revisione del codice dopo commettere

ramo Versione:

• unico sviluppatore di manutenzione
• solo bug fix
prova prove + regressione
• unità
• revisione del codice da 2 altro sviluppatore prima di commettere

ramo Tag:

• non commette dopo la creazione

Developer privato branch:

• Solo i controlli per gli sviluppatori in
• Qualsiasi cambiamento
• Testing necessario solo prima di fondersi al tronco
• La revisione del codice prima di merge al tronco

Se avete il modello di promozione, allora si ha una politica durante lo sviluppo principale, quindi devi dire a tutti quando cambi la politica mentre ti prepari per il rilascio, poi un'altra politica (per la riga di codice) una volta che la linea è stata rilasciata.

Il modello di promozione è facile da raggiungere, si mappa direttamente sul modo di lavorare non di controllo. Ma fa male una volta che inizi a diventare grandi squadre.

Se si osserva lo sviluppo del kernel Linux, è possibile vedere la tensione tra il modello promozionale e il modello Trunk: l'albero di Linus è promozionale - passa attraverso i cicli tra la finestra di fusione e il periodo di stabilizzazione/rc. Ma Linux-next e -mm sono sorti per dare una linea più simile a un tronco.

Gli SCM/VCS distribuiti sono in qualche modo diversi in ogni caso, le politiche non devono essere distribuite a tutti gli sviluppatori perché ogni sviluppo ha i suoi alberi e modifica quando vuole.

I progetti open source soffrono del problema che non possono costringere le persone a eseguire il lavoro di lavoro di stabilizzazione di un rilascio, dopo la derivazione dal trunk. Pertanto, il modello di promozione è più importante come metodo per forzare gli sforzi di stabilizzazione, piuttosto che solo per lavorare sulle funzionalità.

2) Moving lavoro:

Uno sviluppatore potrebbe essere al lavoro su una funzione quando la politica per la linea su cui sta lavorando modifiche al bug-fix solo, ha ora bisogno di cambiare la sua copia di lavoro ad un code-diverso linea. Questo può variare da facile a estremamente difficile a seconda del sistema SCM in uso. Questo problema non si verifica se lo sviluppatore sta lavorando su trunk, poiché il loro lavoro sta andando sempre al trunk.Se lo sviluppatore si trova su una diramazione privata o caratteristica, il loro lavoro influirà solo sul trunk (e sulla release).

Se una funzione è già archiviata, ma viene ritardata dalla versione in cui si trova attualmente, è necessario capire come rimuoverla. Questo problema esiste ancora con il modello di trunk, ma potrebbe essere un po 'più facile da risolvere: scegliere le cose da trunk per il rilascio. Qui è dove aiutano i rami di funzionalità, ma hanno un costo di integrazione.

Answer 2

Subversion consente entrambi gli approcci. Il bagagliaio non è una necessità ma una convenzione. Se ce l'hai, alcuni strumenti funzionano più facilmente (ad esempio strumenti di migrazione per Git). Se non ce l'hai, devi fare alcune cose manualmente ma non riesco a pensare a qualcosa che noterai durante il tuo lavoro quotidiano.

Answer 3

Facciamo - una specie di. Non usiamo un baule, ma creiamo un nuovo ramo per ogni versione dei nostri progetti. Questo ramo 'taggato' è quindi il tronco per ogni versione e eseguiamo il backport di correzioni di errori unendo le modifiche alle versioni precedenti.

Funziona bene per noi, ma nel nostro progetto abbiamo molti sottoprogetti.

Answer 4

Recentemente ho iniziato a lavorare su un progetto che si trova su un repository di subversion. Chiunque abbia creato il repository non ha seguito alcun layout particolare: ha semplicemente inserito tutto nella root del repository (senza trunk /, senza rami/e certamente senza tag /). Volevo creare un ramo su cui lavorare e alcuni tag per altre cose, ma ho realizzato quanto sia difficile farlo su un repository di subversion che non segue un layout corretto.

Answer 5

IME, in alcuni ambienti il ​​trunk è un buon posto per scambiare correzioni e modifiche da/verso. Cioè, tutti uniscono le loro correzioni a il bagagliaio, e tutti uniscono le correzioni degli altri dal bagaglio. Lo abbiamo trovato molto utile in un ambiente in cui un sacco di codice è stato condiviso tra molti progetti indipendenti e in cui tutti questi progetti hanno contribuito al codice condiviso.

L'ambiente potrebbe essere diverso.

Answer 6

Il mio problema con la carta Perforce è che respinge il modello promozionale senza menzionare il vantaggio principale, ridotto overhead di fusione. In effetti, il documento afferma erroneamente che il "modello principale" impone "nessun sovraccarico amministrativo aggiuntivo", una rivendicazione ridicola. Il modello "sempre si fondono in tronco" significa proprio questo: si ha il sovraccarico di chi si deve unire. Ciò è inutile se si ha la seguente situazione (che abbiamo):

a) una piccola squadra (da 5 a 7 sviluppatori) tutti a distanza di gridare l'uno dall'altro. la comunicazione è un non-problema, quando abbiamo bisogno di fare un ramo

e

b) una base di codice in cui v'è mai veramente solo 2 rami principali - un ramo di produzione e "la prossima cosa in fase di sviluppo". Forse una volta in una luna blu abbiamo 3.

Credo che il mio punto sia - è una cosa situazionale. Dire che "il modello promozionale ha problemi" è come dire "non usare mai un OR/M". Dipende dal tuo ambiente.