Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

La struttura del repository

Pianificare e implementare una struttura adeguata per il nostro lavoro
Pianificare e implementare una struttura adeguata per il nostro lavoro
Link copiato negli appunti

Nelle prossime lezioni affrontiamo alcuni argomenti che possono interessare principalmente gli amministratori del server Subversion. Gli utenti finali (programmatori e autori) che usano semplicemente il client per scaricare e caricare modifiche sui progetti non hanno infatti bisogno di acquisire tali competenze, se non per propria curiosità.

La struttura interna

Vista dall'esterno - ad esempio navigandolo con il browser - la struttura del repository sembra corrispondere a quella che noi abbiamo creato per i dati contenuti. Se però andiamo a navigare il filesystem sul server e apriamo la cartella che ospita il repository, troveremo delle cartelle a noi sconosciute. Tali cartelle sono comuni a qualunque repository, e il significato di ciascuna è spiegato di seguito:

  • conf – contiene i file di configurazione del repository
  • dav – contiene i file di lavoro del modulo mod_dav_svn
  • db – contiene il vero e proprio archivio dei nostri dati
  • hooks – contiene gli script di "hook", che affronteremo nella prossima lezione
  • locks – contiene gli eventuali file di lock esistenti

In aggiunta alle cartelle, sono presenti anche un file format che indica la versione del layout del repository (non c'entra nulla con le nostre revisioni, è ad uso del server Subversion), e un file README.txt il cui ruolo è abbastanza ovvio.

Possiamo pensare a questa struttura di cartelle come a un vero e proprio filesystem separato, con le proprie regole e il proprio modo di organizzare i contenuti, che si colloca a un livello superiore rispetto al filesystem di base.

La struttura esterna

Una delle prime scelte da fare quando si crea un server Subversion e tra l'utilizzo di un unico repository per tutti i progetto, oppure la creazione di un repository per ogni progetto

L'utilizzo di un unico repository può ridurre la manutenzione, ma pone dei limiti in termini di flessibilità: diversi progetti potrebbero avere esigenze diverse a livello di accesso e/o di script di automazione. Inoltre, il numero di revisione rimarrebbe comune tra diversi progetti, e questo potrebbe creare confusione.

Il consiglio è senz'altro quello di creare repository diversi per progetti che non hanno nulla a che spartire. Conviene invece mantenere nello stesso repository, magari usando rami diversi, quei progetti che sono in qualche modo correlati, in modo da facilitare l'eventuale scambio di modifiche.

Nelle lezioni precedenti abbiamo visto come sia consigliato creare le cartelle trunk, branches e tags nella cartella principale del progetto. Nel caso si scelga di mantenere un progetto in ogni repository, la cartella principale del progetto corrisponde alla cartella principale del repository:

/
  trunk/
  branches/
  tags/

Nel caso di più progetti uniti nello stesso repository, dovremo invece creare prima le cartelle corrispondenti ai vari progetti, e poi le cartelle in questione:

/
  guidasvn/
    trunk/
    branches/
    tags/
  guidahtml/
    trunk/
    branches/
    tags/

Nulla ci vieta inoltre di creare ulteriori livelli per raggruppare meglio i nostri progetti:

/
  guide/
    guidasvn/
      trunk/
      branches/
      tags/
    guidahtml/
      trunk/
      branches/
      tags/

/
  programmi/
    mybackup/
      trunk/
      branches/
      tags/
    myeditor/
      trunk/
      branches/
      tags/


Ti consigliamo anche