Selv om Subversion lar deg flytte rundt versjonerte filer og kataloger uten tap av informasjon, kan det forstyrre arbeidsflyten til de som ofte aksesserer depotet og forventer at ting er på sine respektive plasser. Prøv å se litt inn i fremtiden; planlegg på forhånd før du plasserer dataene dine under versjonskontroll. Ved å sette opp strukturen på innholdet i depotene dine på en effektiv måte den første gangen, kan du forhindre en drøss med fremtidige hodepiner.

Det er noen få ting å tenke over når du setter opp Subversiondepoter. La oss anta at som depotadministrator, vil du være ansvarlig for å vedlikeholde versjonskontrollsystemet for flere prosjekter. Det første du må bestemme deg for er om du vil bruke et enkelt depot for flere prosjekter, om du vil gi hvert prosjekt sitt eget depot, eller en kombinasjon av disse løsningene.

Det er fordeler med å bruke et enkelt depot for flere prosjekter, først og fremst at du slipper duplisert vedlikehold. Et enkelt depot betyr at det er ett sett med påhakningsskript, én ting å ta backup av, én ting å dumpe og laste hvis Subversion kommer i en ny inkompatibel versjon og så videre. I tillegg kan du lett flytte data mellom prosjekter uten å miste historisk versjonsinformasjon.

Bakdelen med å bruke et enkelt depot er at forskjellige prosjekter kan ha forskjellige postlister eller forskjellige autentiserings- og autorisasjonskrav. Husk også at Subversion bruker globale revisjonsnumre i depotet. Noen liker ikke at selv om ingen forandringer er blitt gjort i deres prosjekt den senere tid, fortsetter likevel det yngste revisjonsnummeret å øke fordi andre prosjekter legger til nye revisjoner.

En kompromissløsning kan også bli brukt. For eksemel kan prosjekter bli gruppert sammen etter hvor relaterte de er til hverandre. Du kan ha noen få depoter med en håndfull prosjekter i hvert av dem. På denne måten kan prosjekter som kan komme til å dele data gjøre dette ganske enkelt, og etterhvert som nye revisjoner blir lagt til depotet, vet utviklerne at disse nye revisjonene ihvertfall er fjernt relaterte på en eller annen måte til alle som bruker dette depotet.

Etter å ha avgjort hvordan du vil organisere prosjektene i henhold til depotene, vil du kanskje tenke over kataloghierarkier i selve depotene. Fordi Subversion bruker vanlige katalogkopier til forgrening og merking (se Kapittel 4, Forgrening og fletting), anbefaler Subversionmiljløet at du velger en katalogplassering for hver prosjektrot – den “øverste” katalogen som inneholder data relatert til det prosjektet – og deretter oppretter tre kataloger under denne roten: trunk som er katalogen der hovedutviklingen av prosjektet foregår; branches som er en katalog som er ment for å lage diverse navngitte grener av hovedutviklingen; tags som er en katalog av grener som er laget, og kanskje ødelagt, men aldri forandret.^[34]

For eksempel kan depotet ditt se ut som dette:

/
   calc/
      trunk/
      tags/
      branches/
   calendar/
      trunk/
      tags/
      branches/
   spreadsheet/
      trunk/
      tags/
      branches/
   …

Legg merke til at det har ingenting å si hvor i depotet hver prosjektrot er. Hvis du har bare ett prosjekt per depot, er den logiske plassen å putte hver prosjektrot i roten av det prosjektets respektive depot. Hvis du har flere prosjekter, vil du kanskje ønske å arrangere dem i grupper innenfor depotet, kanskje legge prosjekter med likelydende mål eller delt kode i den samme underkatalogen, eller kanskje rett og slett gruppere dem alfabetisk. Et slikt system kan se ut som dette:

/
   utils/
      calc/
         trunk/
         tags/
         branches/
      calendar/
         trunk/
         tags/
         branches/
      …
   office/
      spreadsheet/
         trunk/
         tags/
         branches/
      …

Legg opp depotet ditt på den måten du synes passer best. Subversion forventer ikke eller påtvinger deg ikke en spesiell layout – hva Subversion angår, er en katalog en katalog en katalog. Ideelt sett skal du kunne velge det depotoppsettet som fyller behovet til folkene som arbeider på prosjektet som bor der.

Etter at du har bestemt deg for hvordan du vil arrangere prosjektene i depotet ditt, vil du sannsynligvis ønske å fylle depotet med dette oppsettet og de innledende prosjektdataene. Det er et par måter du kan gjøre dette i Subversion. Du kan bruke svn mkdir-kommandoen (se Kapittel 9, Subversion Complete Reference) for å opprette hver katalog i skjelettet av depotlayouten, en etter en. En raskere måte å utføre den samme oppgaven på er å bruke kommandoen svn import (se “svn import”). Ved å først opprette layouten i en midlertidig plassering på harddisken, kan du importere hele katalogtreet inn i depotet i en enkelt innlegging:

$ mkdir tmpdir
$ cd tmpdir
$ mkdir prosjektA
$ mkdir prosjektA/trunk
$ mkdir prosjektA/branches
$ mkdir prosjektA/tags
$ mkdir prosjektB
$ mkdir prosjektB/trunk
$ mkdir prosjektB/branches
$ mkdir prosjektB/tags
…
$ svn import . file:///sti/til/depot --message "Innledende oppsett av depotet"
Adding         prosjektA
Adding         prosjektA/trunk
Adding         prosjektA/branches
Adding         prosjektA/tags
Adding         prosjektB
Adding         prosjektB/trunk
Adding         prosjektB/branches
Adding         prosjektB/tags
…
Committed revision 1.
$ cd ..
$ rm -rf tmpdir
$

Du kan kontrollere resultatene etter importen ved å kjøre kommandoen svn list:

$ svn list --verbose file:///sti/til/depot
      1 harry               May 08 21:48 prosjektA/
      1 harry               May 08 21:48 prosjektB/
…
$

Når du har skjelettet til oppsettet på plass, kan du begynne å importere selve prosjektdataene inn i depotet ditt, hvis noen slike data allerede eksisterer. Som sagt, det er flere måter å gjøre dette på. Du kan bruuke svn import-kommandoen. Du kan hente ut en arbeidskopi fra det nye depotet ditt, flytte og arrangere prosjektdataene inne i arbeidskopien og bruke svn add- og svn commit-kommandoene. Men når vi begynner å snakke om slike ting snakker vi ikke lengre om depotadministrasjon. Hvis du ikke allerede er kjent med svn-klientprogrammet, se Kapittel 2, Grunnleggende bruk.