Du har sett hvordan et depot kan bli aksessert på mange forskjellige måter. Men er det mulig – eller trygt – for depotet å bli aksessert på flere forskjellige måter samtidig?

Til enhver tid kan disse prosessene kreve lese- og skriveaksess til depotet:

Det vanligste problemer administratorer får med å gjøre er eierskap og rettigheter for depotene. Har alle prosesser (og brukere) i den forrige listen rettigheter til å lese og skrive til Berkeley DB-filene? Hvis du har et Unix-lignende operativsystem er en grei måte å plassere hver eneste potensiell depotbruker i en ny svn-gruppe og gjøre denne gruppen til eier av hele depotet. Men til og med dette er ikke nok, fordi en prosess kan skrive til databasefilene med en utrivelig umask – en som forbyr tilgang for andre brukere.

Så det neste steget etter å sette opp en felles gruppe for depotbrukerne er å tvinge alle prosesser som aksesserer depotet til å bruke en fornuftig umask. For brukere som aksesserer depotet direkte kan du kapsle svn-programmet inn i et skript som først setter umask 002 og deretter kjører det egentlige svn-programmet. Du kan skrive et lignende innkapslingsskript for svnserve-programmet, og legge til en umask 002 til Apaches eget oppstartsskript apachectl. For eksempel:

$ cat /usr/bin/svn

#!/bin/sh

umask 002
/usr/bin/svn-real "$@"

Et annet vanlig problem oppstår ofte på Unix-lignende systemer. Når et depot blir brukt, lager Berkeley DB noen ganger nye loggfiler for å journalføre det som den gjør. Selv om hele depotet eies av svn-gruppen, vil ikke disse nye filene nødvendigvis eies av den samme gruppen, som i sin tur fører til flere rettighetsproblemer for brukerne. En grei måte å ordne dette på er å sette gruppens SUID-bit på db-katalogen i depotet. Dette gjør at alle nyopprettede loggfiler tilhører den samme gruppen som foreldrekatalogen.

Når du har gjort alt dette, skal depotet være tilgjengelig for alle de nødvendige prosessene. Det kan se rotete og komplisert ut, men problemene med å ha flere brukere som skal dele skrivetilgang til vanlige filer er klassiske og må løses på måter som ikke er spesielt elegante.

Heldigvis vil de fleste administratorer ikke ha behov for et slikt komplisert oppsett. Brukere som ønsker tilgang til depoter som er på den samme maskinen er ikke begrenset til å bruke URLer av file://-typen, de kan vanligvis kontakte Apache HTTP-serveren eller svnserve ved å bruke localhost som servernavnet i http://- og svn://-URLene. Og det å vedlikeholde flere serverprosesser for Subversiondepotene har en tendens til å skaffe mer hodebry enn nødvendig. Vi anbefaler at du velger den serveren som passer best til dine behov og holder deg til den!