Layout SVN - le migliori pratiche

Question

In CVS che abbiamo sul progetto con più directory in là. V'è una nightly build che deve tirare roba da directory diversa nello stesso progetto CVS al fine di costruire la nightly build. Quindi dovrei avere questo in mente e devo modificare lo script di build per controllare le cose da diversi repository se ci spostiamo a SVN.

Ho letto la relativa SVN QA, ma ho la mia domanda che ho bisogno la risposta per.
Posso fare:

/trunk
/tags
/branches
/3rdparty

Dove tutto sviluppiamo esce dalla / tronco e qualsiasi 3rdparty che non cambiamo va a / 3rdparty.

Tutto bene, ora lo script nightly build deve contrassegnare il tronco, checkout il tag, controlla la 3rdparty roba richiesto nella directory appropriate, quindi avviare il processo di compilazione.
Il risultato build (roba compilato) può rimanere sul NFS per un certo periodo in modo da team di integrazione può tornare indietro 2 settimane e ricreare i problemi.
Sono tutte le mie basi coperte?

Answer 1

Lo SVN Redbook qui include un sacco di informazioni sul layout per diverse tipologie di progetto e come gestirli .

Si consiglia inoltre di utilizzare ganci / trigger / esterni per tirare dentro i dati da un repo indipendente chiamata '3a parte'. Così, quando uno sviluppatore estrae un pronti contro termine, ottiene il 3 ° parte troppo. Ci sono tonnellate di modi per separare le preoccupazioni, ma presentare un pronti contro termine unificato da quelle componenti.

Buona fortuna

Answer 2

Potrebbe essere la pena di fare uso di un motore di generazione come o cruise control Hudson. Il flusso di lavoro è leggermente diverso - i tag vengono effettuate dopo la compilazione, ma è possibile ottenere moduli aggiuntivi che ti danno un certo controllo su questo. Il punto è, tutto il lavoro dev è fatto per voi, e si ottiene un quadro decente per il vostro nightly build, e si ottiene una comoda interfaccia web per controllare e monitorare tutto.

Personalmente, avevo messo alcune definizioni esterne sul tronco di tirare nelle librerie 3a parte appropriate nei luoghi appropriati. In questo modo, quando si cambia terza versione della libreria parti, apportare le modifiche al tronco e non devono modificare gli script di build. Significa anche che è possibile costruire le versioni precedenti solo il check-out il tronco / tag / ramo appropriato. Essere avvertito - appena li fare sul tronco, disperdendoli in giro può portare a un omicidio

.

Mi piacerebbe anche strato repo un po 'come:

project
 /trunk
 /branches
 /tags
3rdparty

Semplicemente perché questo ti dà più spazio per l'aggiunta di altri progetti di alto livello ad un certo punto. In questo modo si consente di gestire diversi progetti in modo completamente indipendente - e si può ancora utilizzare gli esterni per fare riferimento alle versioni di destra da uno all'altro se ci sono dipendenze - questo ben ferma modifiche in un unico progetto in silenzio rottura / modifica progetti dipendenti

.

E 'possibile farlo utilizzando i pronti contro termine separati così, che va bene, ma in quel caso avevo messo a parte la sezione 3rdparty in un repo distinto fin dall'inizio.

Answer 3

Perché non si sposta il terzo partito in tronco? quando ogni si diramano una copia di 3a parte va in filiale. E ovviamente è solito cambiare roba 3rd party in branche perché la vostra filiale è codificato in base alla roba 3a parte esistente.

Io non sono così sicuro di codifica che cosa si sta parlando. E 'questo il numero di versione vuoi dire? Se si tratta di numero di versione passare che attraverso lo script ed etichettare la compilazione.

Answer 4

Se i "più directory" sono componenti separati che si desidera la versione in modo indipendente, allora si dovrebbe avere ciascuno nel proprio repository in modo che possano essere taggati separatamente. Ma se questo è tutto un unico progetto autonomo (vale a dire se si saranno generalmente Tagging e la ramificazione di tutti i componenti insieme), allora probabilmente si può mettere tutto il codice nello stesso repository.

Si dovrebbe considerare l'utilizzo di esterni per la artefatti di terze parti.

Answer 5

Il mio script estrae tronco, modifica i file (regola i numeri di versione in file AssemblyInfo.cs, ecc), quindi i tag che. Se non è necessario modificare i file in alcun modo, quindi etichettare prima sarebbe bene pure.

Oltre a questo, la configurazione suona bene a me almeno.