Organizzare un Subversion repository di migliaia di elementi

Question

Prima di iniziare: ho trascorso molto tempo su molti forum (tra cui Stack Overflow - e sì, ci sono un sacco di domande in modo sull'organizzazione svn), la ricerca di Google, e la lettura di documenti (possiedo un paio di libri Subversion). Non ho ancora trovato un buon modo per organizzare la nostra base di codice in Subversion. Al momento stiamo utilizzando RCS come il nostro sistema di controllo di revisione, e tutto è memorizzato in 1 directory RCS - Brutto, lo so - è per questo che sto lavorando verso qualcosa di meglio. Ho anche usato Subversion molto, quindi so che è capacità e come funziona. Ho esitato a chiedere a questa domanda per mesi, dal momento che non è completamente programmazione relativa, ma dal momento che non sono stato in grado di giungere ad una soluzione, quale posto migliore per porre la mia domanda!

Ciò che complica le cose nella mia testa è il termine "Progetto" sovversione. Se voglio gestire un progetto java in Subversion, questo ha perfettamente senso per me: tutti i file java che vengono combinati in un file JAR potrebbe essere considerato un "progetto" - appartengono tutti insieme. Tuttavia, nel nostro ambiente, non vedo un modo semplice per definire ciò che un "progetto" è. Abbiamo oltre 4.000 programmi, e tutti sono più o meno indipendente l'uno dall'altro. Molti di loro sono script di shell o script perl. Alcuni dei nostri script uso generico "utilità" o gli script di "biblioteca", ma per la maggior parte, tutti gli oggetti di codice sono indepenant.

Un "Progetto" nel nostro ambiente potrebbe comportare il programma A, B, e C, e file di configurazione AA. Un altro progetto potrebbe utilizzare i programmi C, D, ed E, e BB file di configurazione. Ancora un altro progetto potrebbe essere solo cambiando file di configurazione AA, o forse il programma B. Non c'è un modo per classificare i quali programmi o file appartengono a un gruppo. A causa di questo - non ho idea di come organizzare il nostro codice in eversione. Ho potuto mettere tutto in un baule progetto principale, ma poi controllando una copia di lavoro significa check-out elementi tutti oltre 4.000.

Per dare un po 'di contesto, questo è per un Data Warehouse. Tutti gli elementi di codice oltre 4.000 sono necessari per rendere la funzione di magazzino. Forse un certo requisito aziendale viene in che richiede cambiamenti di una colonna a cui si accede in un alcuni degli elementi, e un altro requisito aziendale richiede modifiche ai pochi altri elementi (forse alcuni degli stessi da l'altro progetto).

Forse Subversion non è la soluzione migliore per noi, anche se devo credere che possa funzionare. Abbiamo già un server Subversion per il nostro codice web ed i nostri programmi Java, e funziona benissimo, perché ci sono progetti facilmente definiti. Non riesco proprio a capire come organizzare la nostra libreria di codice principale.

Speriamo che alcuni di quel senso fatto ... Grazie in anticipo per la tua saggezza!

Answer 1

Si potrebbe guardare le esterni proprietà. Esso consente di definire quella cassa di directory in cui è presente proprietà associata, sarà anche checkout altre posizioni all'interno della repository di sottodirectory di quella directory.

Così si potrebbe creare directory "reale" per ogni componente e quindi creare directory separata per ogni progetto che utilizzerà gli esterni per cassa di componenti necessari.

Answer 2

vorrei provare a organizzare la struttura delle cartelle dei file prima semplicemente scaricarli in un repository Subversion.

Credo che il problema risiede principalmente nella disorganizzazione dei file esistenti. Se si riesce a trovare un modo per dividere logicamente il sistema in segmenti, allora sarebbe più facile per permettere alle persone di controllare solo pezzi di file (che sarebbe in raggruppamenti logici).

Subversion rispecchia in realtà un file system, quindi se non sembra abbastanza in un filesystem, non guardare piuttosto in sovversione sia.

Se si vuole evitare di riorganizzare i file, forse si può trovare un sistema di controllo della versione che consente di controllare in / out le cose in base ai tag, invece di dove si trovano nel file system.