Mi sto preparando a configurare un repository SVN e mi chiedevo se qualcuno avesse un buon esempio di struttura del repository. Attualmente sto pensando:Struttura del repository SVN
Sviluppo
.. Applicazioni
.... App1
...... tronco
...... rami
...... tag
.. Database
.. Terzi
Mentre questa struttura probabilmente potrebbe contenere tutto quello che serve, vorrei fare un po 'più granulato. qualche idea?
Abbiamo iniziato con un modello simile, ma lo abbiamo trovato un po 'macchinoso. Il problema principale è che se si desidera diramare il vostro codice di base in un comunicato, si deve andare fare rami per ogni componente.
Invece, abbiamo considerato uno schema come il seguente:
trunk
app1
app2
lib1
lib2
branches
rc-2.0
app1, app2, lib1, lib2...
some-devs-branch
app1, lib2
tags
release-1.0
app1, app2, lib1, lib2...
mi piace avere un repo separata del tutto per le cose di terze parti. A meno che non si prevede di implementare la piena vendor-branching strategy dal red bean book, questo funzionerà bene.
SVN fornisce tag per scattare una "istantanea in tempo" dell'albero di sorgenti in un momento particolare (che è possibile utilizzare per rilasci, ecc.).
Tuttavia, se si intende rendere il repository "più granulato", è consigliabile prendere in considerazione l'impostazione di più repository.
Ovviamente, all'interno della cartella 'trunk', è necessario impostare qualsiasi normale gerarchia di directory se non si fosse utilizzato il controllo del codice sorgente.
Siamo stati strugling con questo.
Abbiamo scoperto che non ci vuole molto tempo prima che alcune librerie condivise siano parte di più applicazioni e si vorrebbe avere tutto sulla stessa versione. Pertanto abbiamo deciso di mettere tutto ciò che facciamo in un unico repostitory. Abbiamo lavorato in questo modo per oltre 2 anni e lo trovo molto bene a lavorare con.
Tutte le configurazioni hanno pro e contro ma avendo un repository completo puoi essere (quasi) sicuro di avere tutti i file insieme nella versione corretta. Se lavori con trunk multipli, ci sono trucchi con cartelle o link virtuali (ho dimenticato il termine) per collegarli tra loro, ma tornare al punto in cui ti trovavi è molto difficile.
Basta ricordare che ogni configurazione ha pro e contro, ma per un'azienda non grande suggerirei di mettere tutto in un unico repository con una cartella principale.
Il mio attuale approccio sta infrangendo i sistemi sui limiti delle applicazioni logiche in un unico repository.
Per esempio, immaginate un servizio che ha anche una suite di test e un database
/project1/application1/
trunk/
Src
Test
Database
tags/
branches/
application2/
trunk/
Src
Test
tags/
branches/
Questo ci permette di avere più applicazioni assoicated con un progetto, ma maniglia di rilascio di controllo per ogni confine applicazione "logica". Considerare dove/quali sono i controlli di rilascio necessari e impostarli come posizione del ramo/tag/struttura del tronco.
Non mi piace la cartella trunk/rami/tag singoli nella directory principale dell'intero repository, perché non voglio che l'intero trunk sia stato estratto, né voglio fare confusione con i checkout di rami parziali come un risultato. (Potrebbe non essere d'accordo e il tuo chilometraggio può variare ecc. Ecc.)
Creiamo sempre un repository SVN separato per ogni "soluzione" separata. Questo repository ha quindi una semplice struttura di trunk, rami e tag.
Qualsiasi framework dipendente (in cui controlliamo il codice sorgente) dispone di un proprio repository separato. In genere, quindi, includiamo solo i binari (in una particolare versione) in qualsiasi progetto che li utilizza.
Avere un unico repository per tutto ciò significa che si hanno buone possibilità di finire con un enorme repository abbastanza velocemente. Ciò significa che le cose possono rallentare e anche un po 'difficile da tracciare. Ovviamente, dipende dal tuo caso d'uso esatto, ma personalmente opterei per i repository per progetto e usando svn: esterni dove necessario.
In realtà, mi piacerebbe optare per un VCS distribuiti su SVN se possibile, ma a ciascuno il suo ...
Cosa si intende per "un po 'più granulato"? –
granulato - Per diventare granulare o granuloso. - Dizionario online gratuito. Penso che volesse dire che vorrebbe perfezionare ulteriormente questa struttura. – mauris
Non possiamo davvero aiutarlo senza conoscere i requisiti del sistema per il quale sta creando un repository. –