La necessità di avere un repository per la gestione del codice sorgente dovrebbe essere ormai un elemento acquisito da parte degli sviluppatori. Tra i più diffusi sistemi di controllo dei sorgenti c'è Subversion, giunto di recente alla versione 1.7. Nella creazione di repository per nuovi progetti software con Subversion, ma anche con altri sistemi, ci si trova spesso a dover fare delle scelte su come strutturarlo, scelte che poi difficilmente potranno essere cambiate.

Jessica Thornsby di WANdisco analizza, in un suo post, i pro e i contro di alcune delle decisioni che uno sviluppatore si trova a dover prendere in questa situazione.

La sua analisi parte dal considerare se, in presenza di più progetti, sia meglio creare un repository per progetto o un unico repository, che ospiti i diversi progetti. Per ciascuna di queste due opzioni ci sono benefici e svantaggi, che dipendono sostanzialmente dalle reciproche relazioni tra i progetti e dall'organizzazione del lavoro del team di sviluppo.

Avere un singolo repository per più progetti può essere comodo quando il codice di un progetto è condiviso con altri, come può avvenire, ad esempio, nel caso di librerie comuni; tuttavia questa opzione può creare qualche problema nell'attribuzione di tag di versione o nella creazione di branch.

La creazione di repository separati per progetto consente, d'altro canto, di avere un maggior controllo sull'accesso da parte degli sviluppatori e di poter definire una struttura del repository più adatta alle caratteristiche del progetto stesso. L'aspetto negativo è rappresentato dal fatto che un progetto software può fare riferimento a diversi repository Subversion a causa dei progetti condivisi.

Per quel che riguarda la struttura del singolo repository, la raccomandazione ufficiale del team di sviluppo di Subversion prevede la creazione delle tre cartelle classiche: trunk, per il codice in sviluppo; branches, per variazioni sostanziali, che potrebbero compromettere la stabilità del codice della release corrente; tags, per l'archiviazione delle milestone del progetto, tipicamente le varie release.

Thornsby suggerisce di affiancare alle cartelle classiche anche altre cartelle per una maggiore discriminazione tra i branch del progetto: per esempio, può tornare utile una cartella per il branch del progetto per testare nuove tecnologie (Toe in the water branches), o un branch specifico per la correzione di bug.