Come strutturi il tuo repository SVN? [chiuso]

Question

Cosa c'è di meglio?

A:

server:1080/repo/projectA/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...
server:1080/repo/projectB/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...

B:

server:1080/repo/trunk/projectA/...
                 branches/projectA/branch1
                 branches/projectA/branch2
                 branches/projectA/branch3
                 tags/projectA/tag1/...
                 tags/projectA/tag2/...
server:1080/repo/trunk/projectB/trunk/...
                 branches/projectB/branch1
                 branches/projectB/branch2
                 branches/projectB/branch3
                 tags/projectB/tag1/...
                 tags/projectB/tag2/...

Quale struttura di repository usi e PERCHÉ?

Answer 1

Il Amministrazione repository del capitolo libro SVN include una sezione su Planning Your Repository Organization delinea le diverse strategie e le loro implicazioni, in particolare le implicazioni del layout del repository su ramificazione e fusione .

Answer 2

Usiamo A, perché l'altro non aveva senso per noi. Tieni presente che un "progetto" per quanto riguarda SVN non è necessariamente un singolo progetto, ma possono essere diversi progetti che appartengono insieme (cioè ciò che si inserirà in una soluzione in Visual Studio). In questo modo, hai raggruppato qualsiasi cosa correlata. Tutti i rami, i tag e il trunk di un progetto specifico. Ha perfettamente senso per me.

Il raggruppamento per ramo / tag invece non ha senso per me, perché i rami di diversi progetti non hanno nulla in comune, tranne che sono tutti rami.

Ma alla fine, le persone usano entrambi i modi. Fai quello che ti piace, ma quando hai deciso, prova a rimanere con esso :)

In aggiunta: abbiamo repository separati per cliente, ovvero tutti i progetti per un cliente si trovano nello stesso repository. In questo modo puoi ad es. eseguire il backup di un singolo cliente contemporaneamente o fornire il codice sorgente di tutto ciò che il cliente gli possiede senza combattere con SVN.

Answer 3

Suggerirei un'opzione C:

server:1080/projectA/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...
server:1080/projectB/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...

Preferisco mantenere progetti separati in repository separati. L'uso di svn: externals semplifica la gestione di progetti di librerie di codici condivisi tra due o più progetti applicativi.

Answer 4

Usiamo l'impostazione B. Perché è più facile controllare / taggare più progetti contemporaneamente. In svn 1.5 è possibile tramite checkout sparse, ma non un'operazione con un clic. Si desidera utilizzare l'impostazione B, se alcuni progetti hanno dipendenze nascoste tra loro.

Answer 5

Usiamo

/repos/projectA/component1/trunk - branches - tags
/repos/projectA/component2/trunk - branches - tags
/repos/projectB/component3/trunk - branches - tags
/repos/projectB/component4/trunk - branches - tags

Di cui sto iniziando a pentirmi. Dovrebbe essere più piatto. Questo sarebbe meglio.

/repos/projectA/trunk - branches - tags
/repos/projectB/trunk - branches - tags
/repos/component1/trunk - branches - tags
/repos/component2/trunk - branches - tags
/repos/component3/trunk - branches - tags
/repos/component4/trunk - branches - tags

Perché? I prodotti (componenti, software finito) durano per sempre. I progetti vanno e vengono. L'anno scorso c'è solo un team di progetto che crea il prodotto QUUX. L'anno prossimo, quella squadra viene dispersa e una o due persone mantengono QUUX. Il prossimo anno, ci saranno due grandi progetti di espansione QUUX.

Considerata questa linea temporale, QUUX dovrebbe apparire in tre repository di progetto? No, QUUX è indipendente da qualsiasi progetto particolare. È vero che i progetti hanno prodotti di lavoro (documenti, arretrati, ecc.) Che fanno parte del lavoro svolto, ma non sono l'obiettivo reale del lavoro. Da qui il "projectX" repository per quel materiale - cose di cui nessuno si preoccuperà dopo che il progetto sarà terminato.

Ho lavorato su un prodotto con tre squadre. Un grosso problema con il coordinamento del lavoro perché ogni progetto ha gestito il proprio repository in modo indipendente. Ci sono stati rilasci tra team e coordinamento tra team. Alla fine della giornata, doveva un pezzo di software. Tuttavia, come puoi immaginare, erano tre software con strane sovrapposizioni e ridondanza.

Answer 6

Personalmente utilizzo la seguente struttura di repository:

/project
    /trunk
    /tags
        /builds
            /PA
            /A
            /B
        /releases
            /AR
            /BR
            /RC
            /ST
    /branches
        /experimental
        /maintenance
            /versions
            /platforms
        /releases

Esiste anche un diagramma che illustra come vengono utilizzate queste directory . Inoltre, utilizzo un approccio di numerazione delle versioni specifico. Svolge un ruolo significativo nella strutturazione del repository. Di recente ho sviluppato una formazione dedicata alla gestione della configurazione del software in cui descrivo l'approccio alla numerazione delle versioni e perché proprio questa struttura di repository è la migliore. Ecco slide di presentazione .

C'è anche la mia risposta sulla domanda su "Repository SVN multipli vs repository per singola azienda". Potrebbe essere utile finché affronti questo aspetto della strutturazione del repository nella tua domanda.