Utilizzando trunk / Filiali e struttura dei tag tra i più sviluppatori

Question

I finiscono per essere confusi quando si tratta di Tronco / branch e tag. Di seguito è la mia domanda:

Abbiamo una squadra di sviluppatori che lavorano su un singolo progetto. Gli sviluppatori sono spesso divisi in gruppi e lavorano su diversi moduli sullo stesso progetto.

Al momento, abbiamo un semplice sistema SVN (senza tronco / rami o Tag), dove tutti lavorano sullo stesso server locale e impegna i file. Ma il problema inizia quando, un paio di sviluppatori lavorano sui moduli futuri (che non dovrebbero andare a vivere immediatamente). In questa situazione, non possono commettere i dati, perché se lo fanno, il loro codice di sviluppo verrà caricato sul server di vivere e finirà per rovinare tutto.

Così, ora sto cercando un qualche tipo di soluzione in cui, questi sviluppatori possono lavorare separatamente, ma sullo stesso codice. Qualcosa di simile a questo:

Uno sviluppatore sta lavorando su nuovo modulo A Developer B sta lavorando su Nuovo modulo B Developer C sta lavorando su correzioni di bug del modulo C (che è già sulle esigenze insetti dal vivo, ma pochi da fissare)

Quindi, Developer A avrà un proprio copia su questa macchina e si impegnerà a repository dello sviluppatore di A. (O ramo)

La stessa logica vale per gli sviluppatori B, ma gli sviluppatori C lavoreranno su una copia comune stabile che sarà da qualche parte in Tag e una volta che il lavoro è fatto, sarà etichettato e spinto al tronco per l'upload sul server di vivere.

Una volta che gli sviluppatori Una è fatto con il lavoro, egli spingerà tutti i suoi file di Trunk per l'upload dal vivo. (Questo dovrebbe unire alcuni file comuni in tronco troppo). Stessa logica vale per gli sviluppatori B.

Non sono sicuro se SVN sarà la soluzione giusta per questo o no. Io non so nemmeno se c'è un modo più semplice da implementare quello che voglio.

Qualsiasi tipo di suggerimenti sono i benvenuti.

Grazie TTR

Answer 1

il mio parere in primo luogo è che se tutti i vostri sviluppatori stanno lavorando su pezzi separati del progetto, allora si può fare via con rami. Si può prendere un po 'di organizzazione (ad esempio i commenti di log propri e delle versioni), ma che può essere molto meno fastidio di ramificazione e la fusione.

Ok, ma se lo fai rami vogliono, sono facili. Ci sono diversi approcci a questo, ma in fondo tutti implicano una versione 'master' in cui il codice finale finisce. questo può essere il tronco, o alcune persone preferiscono fare i cambiamenti sul tronco e quindi unire il codice per rami di rilascio. Il 'tronco è master' è il concetto più facile da cogliere però.

In svn, facendo un ramo è facile - la sua una copia a buon mercato in modo il vostro unico problema si sta riempiendo una directory con le cose (mi raccomando l'eliminazione di un ramo, una volta che hai finito con esso). SVN ti dà un particolare tipo di diramazione per questo tipo di lavoro troppo - ramo reintegrazione . E 'speciale come tracce SVN ciò che accade ad esso, la sua progettato di creare un ramo dal tronco, il lavoro su di esso, di tanto in tanto l'aggiornamento con modifiche che sono state apportate al tronco, e quindi reintegrare tutto il vostro lavoro su quel ramo in tronco in una botto finale. Poi si può ricominciare tutto da capo. Sembra che questo potrebbe essere quello che vuoi - in genere, però, non si avrebbe un ramo per sviluppatore, si avrebbe un ramo per ogni pacchetto di lavoro.

Il problema con rami per-dev è che, come un ramo vive più a lungo e più a lungo, i cambiamenti fanno sarà sempre più difficile tornare unione. Questo è particolarmente vero se gli sviluppatori non si fondono il lavoro dell'altro dev nei loro rami regolarmente (come sono solito fare).

Come svn fa copie a buon mercato, probabilmente raccomandare ramificazione tutto il tronco per ogni sviluppatore. Trovo che la sua più facile da ricordare che, invece di ramificazione singole directory, e sarai sempre in grado di modificare i file condivisi o comuni, senza doversi preoccupare se commettere loro romperanno un ramo diverso. (Cioè se si diramano / trunk / moduleA e poi scopre che è necessario per il cambiamento / trunk / include / common_file quindi il file comune non sarà nella vostra filiale, come si ramificata un sotto-insieme. Quindi, solo ramo alla radice di quella doesn' t ti costa alcun extra)

Answer 2

Nella tua domanda, hai appena espresso il motivo di base dietro l'intero modello tronco / tags / rami - E 'per gestire esattamente questa situazione, che è una situazione normale per un negozio di sviluppo per entrare in dopo un breve periodo <. / p>

Una cosa da piano è la migrazione da un modello senza tronco di un modello di tronco.

È dire che non si dispone di alcun tronco, i tag, rami, ecc Quindi presumo il tuo aspetto modello qualcosa di simile:

/
 filea.html
 fileb.html
 dira/
  filex

Una parola di avvertimento -. non cercare di espandersi nella directory principale in sé

es:

svn cp / /branchA

Ciò si tradurrebbe in una directory che si presenta come:

/
 filea.html
 fileb.html
 dira/
  filex
 branchA/
  ...
 branchB/
  ...

unpicking che cosa è una parte del ramo principale e le sotto-rami diventa piuttosto intrattabile abbastanza rapidamente.

Tenerlo pulito - spostare tutto il codice nel bagagliaio prima. Questo è il tipo di salto strutturale che richiederà tutti (e tutti i sistemi di distribuzione) per eliminare i loro spazi di lavoro e di ottenere tutto da pulire:

svn cp / /trunk

Ora è possibile effettuare tuoi rami:

svn cp /trunk /branches/branchA

Dare una struttura come:

/
 trunk/
  filea.html
  fileb.html
  dira/
   filex
 branches/
  branchA/
   ...

Una volta che i rami sono stati fatti, i dev di possono check them out e lavorare su di essi. Il sistema di distribuzione può puntare a tronco / al posto della cartella principale e quindi distribuirlo.

Le eventuali sviluppatori che lavorano su bug-fix possono checkout tronco. Quando commettono, il sistema di distribuzione sarà distribuire i loro cambiamenti proprio come fanno ora.

Quando branchA è finito, gli sviluppatori possono unire le modifiche nel tronco altrettanto gbjbaanb suggerisce.

solo un rapido testa a testa, buona fortuna con esso.