Det er noen standardiserte, anbefalte måter å organisere et depot på. Mange lager en trunk-katalog for å lagre “hovedlinjen” av utviklingen, en branches-katalog som inneholder grenkopier, og en tags-katalog som inneholder merker. Hvis et depot bare inneholder ett prosjekt, lager man ofte disse toppkatalogene:

/trunk
/branches
/tags

Hvis et depot inneholder flere prosjekter, legger administratorer vanligvis depotet opp etter prosjekt (se “Velge en depot-layout” for å lese mer om “prosjektrøtter”):

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags

Du står selvfølgelig fritt til å ignorere disse vanlige oppsettene. Du kan lage alle mulige varianter, hva som enn fungerer best for deg og ditt team. Husk at hva du enn velger, er du ikke forpliktet til å ha det sånn for alltid. Du kan reorganisere depotet ditt når du vil. Fordi grener og merker er vanlige kataloger, kan svn move-kommandoen flytte eller skifte navn på dem sånn som du ønsker. Å bytte fra et utseende til et annet er bare snakk om å utføre en serie flyttinger på serveren; hvis du ikke liker måten ting er organisert på i depotet, er det bare å ommøblere på katalogene.

Men husk at selv om det å flytte kataloger er en enkel sak, må du også tenke på brukerne dine. Ommøbleringen kan være forvirrende for brukere med eksisterende arbeidskopier. Hvis en bruker har en arbeidskopi fra en spesiell depotkatalog, kan svn move-operasjonen fjerne stien fra den seneste revisjonen. Når brukeren kjører svn update neste gang, vil hun bli fortalt at arbeidskopien hennes representerer en sti som ikke lenger finnes, og brukeren vil bli tvunget til å bruke svn switch for å sette arbeidskopien til den nye plasseringen.

En annen fin funksjonalitet med Subversions modell er at grener og merker kan ha begrenset levetid, akkurat som ethvert annet versjonert element. Tenk deg for eksempel at du etterhvert blir ferdig med alt arbeidet på din personlige gren i calc-prosjektet. Etter at du har flettet alle dine forandringer tilbake til /calc/trunk, trenger ikke grenkatalogen å ligge der mer:

$ svn delete http://svn.example.com/repos/calc/branches/min-calc-gren \
             -m "Fjerner avlegs gren i calc-prosjektet."

La inn revisjon 375.

Og nå er forgreningen borte. Vel, selvfølgelig er den ikke egentlig borte, katalogen mangler bare fra HEAD-revisjonen og distraherer dermed ingen. Hvis du bruker svn checkout, svn switch eller svn list for å undersøke en tidligere revisjon, vil du fortsatt være i stand til å se den gamle grenen din.

Hvis det ikke er nok å bare undersøke den slettede katalogen, kan du alltids hente den tilbake. Å hente tilbake data i Subversion er veldig enkelt. Hvis det er en slettet katalog (eller fil) som du vil hente tilbake inn i HEAD, kan du bruke svn copy -r for å kopiere den fra den gamle revisjonen:

$ svn copy -r 374 http://svn.example.com/repos/calc/branches/min-calc-gren \
                  http://svn.example.com/repos/calc/branches/min-calc-gren

La inn revisjon 376.

I eksempelet vårt hadde den personlige grenen din en relativt kort levetid, du kan ha laget den for å ordne en feil eller legge til en ny funksjonalitet. Når oppgaven din er gjort, er levetiden til grenen over. Men innen programutvikling er det også vanlig å ha to “hoved”-grener som lever ved siden av hverandre for veldig lange perioder. For eksempel, tenk deg at det er på tide å utgi en stabil versjon av calc-prosjektet til offentligheten, og du vet at det kommer til å ta noen måneder å luke ut feil av programmet. Du vil ikke at folk skal legge inn ny funksjonalitet til prosjektet, men du vil heller ikke at utviklerne skal stoppe programmeringen. Så istedenfor lager du en “stabil” gren av programmet som ikke vil forandre seg så mye:

$ svn copy http://svn.example.com/repos/calc/trunk \
         http://svn.example.com/repos/calc/branches/stabil-1.0 \
         -m "Lager stabil gren av calc-prosjektet."

La inn revisjon 377.

Og nå kan utviklerne fortsette med å legge til rykende ferske (eller eksperimentelle) funksjoner til /calc/trunk, og du kan lage en regel for prosjektet som sier at kun feilrettinger skal legges inn i /calc/branches/stabil-1.0. Det vil si, mens brukerne fortsetter å arbeide i trunk, kan feilrettinger selektivt bli flettet over til den stabile grenen. Selv etter at den stabile grenen er på markedet, vil du sannsynligvis fortsette å vedlikeholde grenen i lang tid – det vil si så lenge du fortsetter med å vedlikeholde utgivelsen for kunder.