Utilizzando Subversion con il modello promozionale

Question

Al momento usiamo Subversion per controllo del codice sorgente, ma tutto il lavoro che si fonde per i nostri comunicati è fatto manualmente. Rilasciamo diverse volte l'anno, in modo da creare un ramo per ogni release. Tutto il lavoro da rami precedenti deve fare in quelle successive. Il lavoro sui rami successivi non deve farne quelle precedenti (questo è nei nostri contratti). Credo che questo è noto come il modello promozionale.

Credo che il seguente diagramma illustra meglio il nostro flusso di lavoro desiderato, con filiali in fase di creazione ogni volta che il lavoro inizia una nuova release, e le modifiche che scorre da rami precedenti a quelle successive.

|
1
|
|\
| \ 
| 2 
3 | 
|\| 
4 |
| |\
5 | \
| 6 |
| | 7
|\|\|
| |\|
8 9 |\
| | | \
|\| | 10
x |\| |
  | |\|
  | | | 

a b c d

• Sarebbe questo modello di lavoro senza problemi utilizzando Subversion, nonostante la mancanza di un tronco di significato?
• Sarebbe automatizzato merge di monitoraggio di lavoro per gli aggiornamenti da rami precedenti a quelle successive?
• Sarebbe ok per chiudere / cancellare / ignorare un ramo (in questo ramo di release esempio 'a') senza reintegrare?
• Sarebbe OK per creare funzionalità rami fuori di ogni ramo di release, e si sarebbe fusa lavoro di monitoraggio per questi? (Avrebbero seguire il merge modello consigliato creare / / Reintegrazione.)

Modifica - aggiungere ulteriori informazioni

.

La ragione per cui il modello Tronco Instabile tradizionale potrebbe non essere adatto è illustrato dal seguente schema. Caratteristiche per ogni release non sono necessariamente completate in ordine di rilascio (alcuni clienti possono essere lento per confermare i requisiti). Vogliamo per propagare le modifiche da rami precedenti a quelle successive al più presto possibile.

    a
    |
    1
    |
   b|\ a
    | \ 
    |  2
    3  |
    |  |
    4  |
  b/|c |
  / 5  |
 |  |  6
 7  |  |
 b  c  a

In questo caso, vogliamo caratteristica 2 (completato nel ramo a) nel ramo B, ma come questo è una fusione bambino-to-genitore, e quindi non supportato da Subversion, esso dovrà essere fatto manualmente. Analogamente, caratteristica 6 dovrebbe essere manualmente fuse due volte. I anticipare che questo è un processo relativamente lento e soggetto a errori rispetto a unioni rilevate automaticamente.

Answer 1

Se ho capito la tua situazione, non c'è nulla nei vostri requisiti che rendono le cose come complesso come ti sembra di essere loro fare. Sei anche mettendo modo troppa enfasi sui meriti di automatica vs. fusione manuale (ne riparleremo più avanti). rami CVS sarebbe stato un altro discorso, ma non con il modo in cui gestisce i SVN "rami" (vale a dire, non lo fa).

Si potrebbe avere un primario linea di sviluppo (instabile o stabile) e creare filiali per ogni cliente o il rilascio (o entrambi). Come caratteristiche sono convalidati, essi o vengono fuse di nuovo alla linea principale in modo da rami successivi possono includere le modifiche o si fondono sempre unidirezionale da un ramo genitore. Nulla richiede di chiudere il ramo e l'unione non è meno automatizzata di quanto lo sarebbe stato per sostenere il vostro primo schema (caotico) dato si dispone di più linee di sviluppo concorrenti.

Il requisito che si uniscono solo in avanti suona come avete solo bisogno di unire le revisioni sottoinsieme dalla linea principale, revisioni dopo un dato di revisione ramo. Facendo i tuoi fonde in questo modo vi permetterà di unire le modifiche da rami arbitrari di nuovo alla linea principale, come le volte che vuoi (come essi sono confermate con i clienti) e possono essere applicati in avanti con la sicurezza che sono sempre applicate modifiche solo convalidati. È possibile impostare la fusione automatica per monitorare che la revisione della copia (vedi --stop-on-copy e fonde gamma-based). rami di rilascio poi raccogliere insiemi di modifiche confermato che si sono verificati da un dato punto in avanti.

SVN non "track fonde" più di quanto supporta rami (che non è così, sono solo copie leggeri). Si dice (o svnmerge la racconta) va a fondersi e si applica tali modifiche. È possibile ottenere l'effetto che si sta contrattualmente tenuti a sostenere, a prescindere.

Per rispondere alle vostre domande poste:

• Non credo che il modello avete proposto è molto efficace. Al contrario, essa ha aumentato le possibilità funzionalità di rilevamento caos come potrebbe essere necessario eseguire la scansione rami per le modifiche e si fondono in avanti più volte. Inoltre, sarà senza dubbio confondere gli sviluppatori che hanno familiarità con SVN e più tradizionali strutture organizzative SVN.

• Certo. Questo dovrebbe essere abbastanza indipendente dalla struttura si è scelto anche. Si sta andando ad avere bisogno / voglia di tenere traccia dei vostri punti di revisione a prescindere (magari attraverso qualche semplice script in peggio).

• Certo. Filiali sono effettivamente senza alcun costo in SVN sul lato server. Il lato client ha un costo se si fa intere casse di root, ma che è generalmente una cosa stupida da fare a prescindere. Allo stesso modo, non c'è nessun problema ignorando / eliminazione di un ramo. E 'solo un altro cambio alla gerarchia di revisione globale come qualsiasi altra copia / cancellare / rinominare / etc.

• Che dovrebbe funzionare indipendentemente dal "ramificazione" struttura organizzativa messo in atto. Sembra che ci sia un forse po 'di equivoco su ciò che significa essere un "ramo" in SVN. Si dovrebbe essere in grado di creare ciò che si vuole ed eseguire 'manuale' si fonde con relativa facilità a prescindere e poi impostare la fusione automatica dopo un paio di aggiornamenti dei clienti in modo da poter capire la stampa passi un po 'meglio.

Cheers!

Answer 2

Tu dici:

  

Tutti i lavori da rami precedenti deve   trasformarlo in quelle successive. Lavorare in un secondo momento   rami non devono rendere in precedenza   quelli (questo è nei nostri contratti)

Qui, se si sostituisce rami con stampa (dubito vostri clienti conoscono o si preoccupano di "rami"), otteniamo:

  

Tutto il lavoro da versioni precedenti deve   trasformarlo in quelle successive. Lavorare in un secondo momento   comunicati che non devono fare in precedenza   quelli (questo è nei nostri contratti)

Non vedo nulla in tale requisito per suggerire lo schema di ramificazione molto complessa che proponete - si può fare questo con il classico stile "tronco instabile" dello sviluppo. O si hanno più i requisiti non ci hanno raccontato, o avete più di-engineering.