Usa Subversion senza Trunk

Question

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

Qualcun altro là fuori lo fa?

Se sì, hai notato dei pro/contro?

Anche se il tuo team non lo fa, qualcuno ha qualche idea su questo layout?

Answer 1

Si sta parlando della modello promozionale - carta di Perforce evidenzia i problemi con esso -. comunicanti del ruolo dei codici linee e spostamento di lavoro tra i rami

Un'espansione su mie opinioni dei problemi elencati:

1) Modifica politica di code-linee:

Ogni riga di codice ha una politica, che si tratti di scritto e formalizzato, o interamente implicita nella testa di uno sviluppatore. Definisce per esempio:

• chi ha il permesso di impegnarsi per il codice riga
• è richiesto quanto i test (Per esempio fare l'unità test devono passare, test di regressione, test completo del sistema)
• quante persone hanno codificare recensione modifiche
• che tipo di cambiamenti sono permesso

Con l'approccio tronco, le politiche rimangono fissi, quindi sono più facili da scrivere, che li rende più facili da comunicare (più importante in una squadra più grande).

es. Tronco:

• qualsiasi sviluppatore può commettere
• alcuna variazione
• unit test devono passare
• la revisione del codice dopo il commit

ramo Versione:

• unico sviluppatore di manutenzione
• solo bug fix
test
• unit test di regressione +
• la revisione del codice da 2 altro sviluppatore prima di commettere

ramo Tag:

• non commette dopo la creazione

private branch dello sviluppatore:

• Solo i controlli per sviluppatori in
• Qualsiasi modifica
• Test necessario solo prima di fondersi al tronco
• La revisione del codice prima della fusione al tronco

Se avete il modello di promozione, allora avete una politica, mentre in fase di sviluppo principale, poi a dire a tutti quando si cambia la politica durante la preparazione per il rilascio, poi un'altra politica (per la linea di codice) una volta che la linea viene rilasciato.

Il modello promozione è un compito facile da raggiungere, ma le mappe direttamente sul controllo di modo non fonte di lavoro. Ma fa male una volta che si avvia sempre grandi squadre.

Se si guarda allo sviluppo del kernel di Linux si può vedere la tensione tra il modello promozionale e il modello del tronco: Albero di Linus' è promozionale - passa attraverso cicli tra la finestra unione, e il periodo di rc / stabilizzazione. Ma Linux-next e -mm sono sorti per dare una più tronco come la linea.

SCM Distribuito / VCS sono un po 'diversa in ogni caso, le politiche non devono essere distribuiti a tutti gli sviluppatori, perché ogni sviluppo ha i suoi alberi, e tira le modifiche quando vuole.

progetti open-source hanno il problema che non può obbligare la gente a fare il lavoro sgobbone di stabilizzare un comunicato, dopo la ramificazione dal tronco. Pertanto il modello di promozione è più importante come un modo di forzare sforzi di stabilizzazione, piuttosto che lavorare sulle caratteristiche.

lavoro

2) Moving:

Uno sviluppatore potrebbe essere al lavoro su una funzione quando la politica per la linea su cui sta lavorando modifiche al bug-fix solo, ora ha bisogno di cambiare la sua copia di lavoro ad un diverso codice di linea. Questo può essere ovunque da facile a molto difficile a seconda del sistema SCM in uso. Questo problema non si verifica se lo sviluppatore sta lavorando sul tronco, come il loro lavoro sta andando sempre tronco. Se lo sviluppatore è su un ramo privato o una funzione, allora il loro lavoro graverà solo sul tronco (e la liberazione) a tutti.

Se una funzione è già selezionata, ma viene ritardato dalla versione che è attualmente in, è necessario capire come rimuoverlo. Questo problema ancora esistente con il modello del tronco, ma potrebbe essere un po 'più facile da risolvere - cose cherry-picking dal tronco per il rilascio. Questo è dove aiutano questi rami -. Ma hanno un costo di integrazione

Answer 2

Il mio problema con la carta Perforce è che respinge il modello promozionale senza menzionare il vantaggio principale, riduce la fusione sovraccarico. Infatti, il documento afferma erroneamente che il "modello mainline" impone "alcun overhead amministrativo supplementare", un credito ridiculuous. Il modello "sempre si fondono per trunk" significa solo che - si ha la testa di ognuno dover unire. Questo è sovraccarico inutile se si ha la seguente situazione (che abbiamo):

a) un piccolo gruppo (da 5 a 7 gli sviluppatori), tutti a portata di voce 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 davvero 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 è - è una cosa situazionale. A dire il "modello di promozione ha dei problemi" è come dire "non usare mai un OR / M". Dipende dal vostro ambiente.

Answer 3

Subversion permette entrambi gli approcci. Il tronco non è una necessità ma una convenzione. Se lo avete, alcuni strumenti di lavorare più facilmente (per esempio, gli strumenti di migrazione per Git). Se non lo avete, è necessario fare alcune cose manualmente, ma non riesco a pensare a qualcosa che si noterà durante il vostro lavoro quotidiano.

Answer 4

Recentemente ho iniziato a lavorare su un progetto che si trova su un repository subversion. Chi ha creato il repository non ha seguito alcuna disposizione particolare - semplicemente ripieni tutto nella radice del repository (senza tronco /, senza rami /, e certamente nessun tag /). Volevo creare un ramo su cui lavorare e alcuni tag per altre cose, ma sono reso conto quanto sia difficile farlo in un repository Subversion che non segue un layout adeguato.

Answer 5

Facciamo - sorta di. Non usiamo un tronco, ma creare un nuovo ramo per ogni release dei nostri progetti. Questo ramo 'tag' è poi il tronco per ogni versione, e noi backport correzioni attraverso la fusione modifiche sulla release precedenti.

Funziona bene per noi, ma abbiamo un sacco di sottoprogetti nel nostro progetto.

Answer 6

IME, in alcuni ambienti il ​​trunk è un buon posto per scambiare correzioni e modifiche da/verso.Cioè, tutti uniscono le loro correzioni A nel bagagliaio e tutti uniscono le correzioni degli altri da il bagagliaio.Lo abbiamo trovato molto utile in un ambiente in cui molto codice veniva condiviso tra molti progetti indipendenti e in cui tutti questi progetti contribuivano al codice condiviso.

Tuttavia, il tuo ambiente potrebbe essere diverso.