Opprettelse og konfigurering av depotet

Opprettelse og konfigurering av depotet
Forrige	Kapittel 5. Depotadministrasjon	Neste

Det å opprette et Subversiondepot er en utrolig enkel oppgave. svnadmin-verktøyet som følger med Subversion har en delkommando som gjør akkurat det. For å opprette et nytt depot, er det bare å kjøre:

$ svnadmin create /sti/til/depot

Dette oppretter et nytt depot i katalogen /sti/til/depot. Dette nye depotet starter livet ved revisjon 0, som er definert til å bare innholde en rot på toppnivå (/) i filsystemet. Revisjon 0 har også en enkelt revisjonsegenskap satt innledningsvis, svn:date, som er satt til tidspunktet depotet ble opprettet.

I Subversion 1.2 blir et depot opprettet i FSFS-formatet som standard (se “Datalagring i depotet”). Formatet kan bli eksplisitt valgt med --fs-type-valget:

$ svnadmin create --fs-type fsfs /sti/til/depot
$ svnadmin create --fs-type bdb /sti/til/annet/depot

Advarsel

Opprett ikke et Berkeley DB-depot på en nettverksdisk – det kan ikke eksistere på et fjerntliggende filsystem som NFS, AFS eller Windows SMB. Berkeley DB krever at det underliggende filsystemet har implementert streng POSIX låsesemantikk, og enda viktigere, muligheten til å mappe filer direkte inn i prosesshukommelsen. Nesten ingen nettverksfilsystemer tilbyr disse mulighetene. Hvis du forsøker å bruke Berkeley DB på en nettverksdisk, er resultatene uforutsigelige – du kan se mystiske feilmeldinger med en gang, eller det kan gå månedsvis før du oppdager at depotet i all stillhet blir herpa.

Hvis du trenger flere datamaskiner for å aksessere depotet, lager du et FSFS-depot på nettverksdisken, ikke et Berkeley DB-depot. Eller enda bedre, sett opp en skikkelig serverprosess (som for eksempel Apache eller svnserve), legg depotet i et lokalt filsystem som serveren kan aksessere og gjør depotet tilgjengelig over et nettverk. Kapittel 6, Serverkonfigurasjon dekker denne prosessen i detalj.

Du har kanskje lagt merke til at stiargumentet til svnadmin bare var en vanlig filsystemsti og ikke en URL lik det svn-klienten bruker når den refererer til depot. Både svnadmin og svnlook ansees som serverside-verktøy – de blir brukt på maskinen hvor depotet ligger for å undersøke og modifisere aspekter ved depotet, og er faktisk ikke i stand til å utføre oppgaver over nettverket. En vanlig feil som blir gjort av nybakte Subversionbrukere er å gi URLer (til og med av typene “local” og file:) til disse to programmene.

Så, etter at du har kjørt svnadmin create-kommandoen, har du et skinnende nytt depot i sin egen katalog. La oss ta en kikk på hva som egentlig er laget i denne katalogen.

$ ls depot
conf/  dav/  db/  format  hooks/  locks/  README.txt

Med unntak av filene README.txt og format, er depotkatalogen en samling av underkataloger. Som i andre områder av Subversion-designet er modularitet gitt stor oppmerksomhet, og hierarkisk organisering er foretrukket framfor rotete kaos. Her er en rask beskrivelse av alle elementene som du ser i den nye depotkatalogen:

conf: En katalog som inneholder konfigurasjonsfiler for depotet.
dav: En katalog der Apache og mod_dav_svn lagrer sine husholdningsdata.
db: Der alle dine versjonerte data ligger. Denne katalogen er enten et Berkeley DB-miljø (full av databasetabeller og andre ting) eller et FSFS-miljø som inneholder revisjonsfiler.
format: Ei fil som inneholder en enkelt heltallsverdi som spesifiserer versjonsnummeret til depotlayouten.
hooks: En katalog full av maler for påhakningsskript (Engelsk: hooks) og påhakningsskriptene selv, når du har installert noen.
locks: En katalog for Subversions låsedata, brukt for å følge tilganger til depotet.
README.txt: Ei fil som bare informerer sine lesere om at de ser på et Subversiondepot.

Generelt sett skal du ikke fikle med depotet “for hånd”. svnadmin-verktøyet skal være nok til alle nødvendige forandringer i depotet, eller du kan se på tredjeparts verktøy (som Berkeley DBs verktøysamling) for å finpusse relevante delseksjoner av depotet. Noen unntak gjelder imidlertid, og disse skal vi gå gjennom her.

Påhakningsskript

Et påhakningsskript (på engelsk kalt hooks) er et program som blir utløst av en hendelse i depotet, som for eksempel opprettelsen av en ny revisjon eller modifiseringen av en uversjonert egenskap. Hver påhakning blir gitt nok informasjon til å fortelle hva denne hendelsen er, hvilke mål den opererer på, og brukernavnet til personen som satte i gang hendelsen. Avhengig av påhakningens utdata eller returstatus, kan påhakningsprogrammet fortsette hendelsen, stoppe den, eller utsette den på en eller annen måte.

hooks-katalogen er, som standard, fylt med maler for diverse depotpåhakninger.

$ ls depot/hooks/
post-commit.tmpl          post-unlock.tmpl          pre-revprop-change.tmpl
post-lock.tmpl            pre-commit.tmpl           pre-unlock.tmpl
post-revprop-change.tmpl  pre-lock.tmpl             start-commit.tmpl

Det er en mal for hver påhakning som Subversiondepotet implementerer, og ved å undersøke innholdet til disse eksempelskriptene, kan du se hva som fører til at hvert av disse skriptene begynner å kjøre og hvilke data som blir levert til dette skriptet. Det som også ligger i mange av disse malene er eksempler på hvordan man kan bruke skriptet i sammenheng med andre programmer som følger med Subversion for å utføre vanlige, nyttige oppgaver. For å faktisk installere en påhakning som virker, trenger du bare å plassere et kjørbart program eller skript i depot/hooks-katalogen som kan bli kjørt basert på navnet (som for eksempel start-commit eller post-commit) til påhakningen.

På Unix-plattformer betyr dette å legge inn et skript eller program (som kan være et shellskript, et Pythonprogram, et kompilert C-program, eller hva som helst annet) som heter akkurat det samme som påhakningen. Selvfølgelig, malfilene er der for mer enn bare informasjonsverdien – den letteste måten å installere en påhakning på Unixplattformer er å bare kopiere den riktige malfila til ei ny fil som mangler .tmpl-etternavnet, finpusse på innholdet, og forsikre deg om at skriptet er kjørbart. Men Windows bruker filetternavn til å avgjøre hvorvidt et program er kjørbart eller ikke, så da må du legge inn et program der hovednavnet er navnet på påhakningen, og der etternavnet er en av de spesielle etternavnene som Windows kjenner igjen som kjørbare, for eksempel .exe eller .com for programmer, og .bat for batchfiler.

Tips

Av sikkerhetsgrunner kjører Subversion påhakningsskript med et tomt miljø (environment) – det betyr, ingen miljøvariabler er satt i det hele tatt, ikke engang $PATH eller %PATH%. På grunn av dette blir mange adminstratorer forvirret når påhakningsskriptet kjører fint for hånd, men virker ikke når det blir kjørt av Subversion. Pass på å eksplisitt sette variabler i skriptet og/eller bruk absolutte stier til programmer.

Det er lagt inn ni påhakninger i Subversiondepotet:

start-commit

Denne blir kjørt allerede før innleggingstransaksjonen er opprettet. Det blir vanligvis brukt til å avgjøre om brukeren har innleggingsprivilegier i det hele tatt. Depotet leverer to argumenter til dette programmet: Stien til depotet, og brukernavnet som forsøker seg på innleggingen. Hvis programmet returnerer en verdi som ikke er null, blir denne innleggingen stoppet allerede før transaksjonen blir laget. Hvis påhakningen skriver data til standardfeil, vil det bli sendt tilbake til klienten.

pre-commit

Dette blir kjørt når transaksjonen er komplett, men før den er lagt inn. Vanligvis blir denne påhakningen brukt til å beskytte mot innlegginger som er forbudt på grunn av innhold eller beliggenhet (for eksempel kan serveren kreve at alle innlegginger til en spesiell gren inneholder et billettnummer fra feildatabasen, eller at den innkommende loggmeldingen ikke er tom). Depotet leverer to argumenter til dette programmet: Stien til depotet, og navnet på transaksjonen som legges inn. Hvis programmet returnerer en verdi som ikke er null, avbrytes innleggingen og transaksjonen blir fjernet. Hvis programmet skriver data til stderr, vil dette bli sendt tilbake til klienten.

Subversiondistribusjonen inneholder noen aksesskontrollskript (i tools/hook-scripts-katalogen i kildekodefiltreet til Subversion) som kan bli kalt fra pre-commit for å kunne legge inn finjustert kontroll for skriveaksess. En annen mulighet er å bruke Apache-modulen mod_authz_svn som gir både lese- og skrivekontroll i individuelle kataloger (se “Adgangskontroll på katalognivå”). I en framtidig versjon av Subversion planlegger vi å legge inn lister for aksesskontroll (ACL) direkte inn i filsystemet.

post-commit

Dette blir kjørt etter at transaksjonen er lagt inn, og en ny revisjon er opprettet. De fleste vil bruke denne påhakningen til å sende ut beskrivende eposter om innleggingen eller for å ta backup av depotet. Depotet gir to argumenter til dette programmet: Stien til depotet, og det nye revisjonsnummeret som ble opprettet. Returverdien fra programmet blir ignorert.

Subversiondistribusjonen inneholder skriptene mailer.py og commit-email.pl (i tools/hook-scripts/-katalogen i Subversiontreet) som kan bli brukt til å sende epost med (og/eller legge til en loggfil) en beskrivelse av en mottatt innlegging. Denne mailen inneholder en liste over de stiene som ble forandret, loggmeldingen som er vedlagt innleggingen, forfatteren og datoen til innleggingen, sammen med en GNU diff-visning av forandringene som ble gjort til diverse filer som del av innleggingen.

Et annet nyttig verktøy som følger med Subversion er skriptet hot-backup.py (i tools/backup/-katalogen i kildekodetreet til Subversion). Dette skriptet tar “varme” backuper av Subversiondepotet (en funksjonalitet støttet av den bakenforliggende Berkeley DB-databasen), og kan bli brukt til å foreta en øyeblikkslagring av depotet mellom hver innlegging for arkiverings- eller sikkerhetsformål.

pre-revprop-change

Fordi Subversions revisjonsegenskaper ikke er versjonerte, vil det å forandre slike egenskaper (for eksempel svn:log-egenskapen som inneholder loggmeldingen for innleggingen) overskrive den forrige verdien for alltid. Siden data kan gå tapt her, har Subversion denne påhakningen (og dens motstykke post-revprop-change) så depotadministratorer kan lage logger med forandringer i disse elementene ved bruk av eksterne hjelpemidler hvis de vil det. Som en forholdsregel mot å miste uversjonerte data, vil ikke Subversionklienter få lov til å forandre revisjonsegenskaper i det hele tatt hvis ikke denne påhakningen er aktivisert i depotet ditt.

Denne påhakningen kjører like før en slik modifisering blir lagt inn i depotet. Depotet leverer fire argumenter til denne påhakningen: Stien til depotet, revisjonen som egenskapen som skal forandres befinner seg på, det autentiserte brukernavnet til personen som gjør forandringen, og navnet på selve egenskapen.

post-revprop-change

Som nevnt tidligere, er denne påhakningen motstykket til pre-revprop-change-påhakningen. For paranoiaens skyld vil faktisk ikke dette skriptet kjøre uten at pre-revprop-change-skriptet finnes. Når begge disse skriptene finnes, kjører post-revprop-change-påhakningen like etter at en revisjonsegenskap er blitt forandret, og blir vanligvis brukt til å sende en epost som inneholder den nye verdien til den forandrede egenskapen. Depotet leverer fire argumenter til denne påhakningen: Stien til depotet, revisjonen som egenskapen tilhører, det godkjente brukernavnet til personen som gjør forandringen, og navnet på selve egenskapen.

Subversiondistribusjonen inkluderer skriptet propchange-email.pl (i tools/hook-scripts/-katalogen i Subversions kildekodetre) som kan bli brukt til å sende epost med (og/eller legge til en loggfil) detaljene om en egenskapsforandring. Denne eposten inneholder revisjonen og navnet til den forandrede egenskapen, brukeren som gjorde forandringen, og den nye verdien til egenskapen.

pre-lock

Denne påhakningen kjøres hver gang noen prøver å låse ei fil. Den kan bli brukt til å forby låser i det hele tatt, eller å definere et mer komplekst regelsett som spesifiserer nøyaktig hvilke brukere som får lov til å låse spesielle stier. Hvis påhakningen finner en allerede eksisterende lås, kan den også bestemme om en bruker har lov til å “stjele” den eksisterende låsen. Depotet leverer tre argumenter til påhakningen: Stien til depotet, stien som blir låst, og navnet på brukeren som prøver å utføre låsingen. Hvis programmet returnerer en verdi som ikke er null, blir låseprosessen avbrutt og alt som blir skrevet til standard feil blir sendt tilbake til klienten.

post-lock

Denne påhakningen kjører etter at en sti er låst. Den låste stien sendes til påhakningens standard inn, og påhakningen mottar også to argumenter: Stien til depotet og brukeren som utførte låsingen. Skriptet kan dermed sende melding via epost eller logge hendelsen på den måten som er bestemt. Fordi låsingen allerede har skjedd, blir utdataene fra påhakningen ignorert.

pre-unlock

Denne påhakningen kjøres når noen prøver å fjerne en lås på ei fil. Den kan brukes til å lage regler som spesifiserer hvilke brukere som har lov til å låse opp spesielle stier. Den er spesielt viktig for å avgjøre regler om bryting av låser. Hvis bruker A låser ei fil, får bruker B lov til å bryte låsen? Hva hvis låsen er mer enn en uke gammel? Denne typen ting kan bli bestemt og gjennomført av påhakningen. Depotet leverer tre argumenter til påhakningen: Stien til depotet, stien som låses opp, og navnet på brukeren som prøver å fjerne låsen. Hvis programmet returnerer en verdi som ikke er null, blir opplåsingsprosessen avbrutt og alt som blir skrevet til standardfeil leveres til klienten.

post-unlock

Denne påhakningen kjøres etter at en sti er låst opp. Stien som er låst opp sendes til skriptets standard inn, og det mottar også to argumenter: Stien til depotet og brukeren som fjernet låsen. Påhakningen kan dermed sende epost eller logge hendelsen på den måten som er valgt. Fordi fjerningen av låsen allerede har skjedd, blir utdataene fra påhakningen ignorert.

Advarsel

Ikke forsøk å forandre transaksjonen ved å bruke påhakningsskript. Et vanlig eksempel på dette ville være å automatisk sette egenskaper som svn:eol-style eller svn:mime-type under innleggingen. Selv om dette kan se ut som en god idé, fører det til problemer. Hovedproblemet er at klienten ikke vet om forandringen gjort av påhakningsscriptet, og det er ingen måte å informere klienten om at den er utdatert. Denne inkonsekventheten kan føre til overraskende og uventet oppførsel.

Istedenfor å forsøke å modifisere transaksjonen, er det mye bedre å sjekke transaksjonen i pre-commit og nekte innlegging hvis den ikke møter de ønskede kravene.

Subversion vil forsøke å kjøre påhakningsskriptene som den samme brukeren som eier prosessen som aksesserer Subversiondepotet. I de fleste tilfeller blir depotet aksessert via Apache HTTP-serveren og mod_dav_svn, så denne brukeren er den samme som Apache kjører som. Selve påhakningene må bli satt opp med rettigheter på operativsystemnivå som tillater denne brukeren å kjøre dem. Dette betyr også at enhver fil eller program (inkludert selve Subversiondepotet) aksessert direkte eller indirekte av påhakningen vil bli aksessert som den samme brukeren. Med andre ord, vær obs på mulig rettighetsproblematikk som kan forhindre påhakningsskriptet fra å utføre de oppgavene du har satt det til.

Konfigurasjon av Berkeley DB

Et Berkeley DB-miljø er en innkapsling av en eller flere databaser, loggfiler, regionfiler og konfigurasjonsfiler. Berkeley DB-miljøet har sitt eget sett med konfigurasjonsverdier for ting som antallet databaselåser som er tillatt brukt på en gang, maksimal størrelse på journalloggfiler og så videre. Subversions filsystemkode velger i tillegg standardverdier for noen av konfigurasjonsvalgene i Berkeley DB.

Folkene i Sleepycat (produsentene av Berkeley DB) innser at forskjellige databaser har forskjellige krav, og de har derfor lagt inn en mekanisme for å overstyre mange av konfigurasjonsverdiene til Berkeley DB under kjøring. Berkeley sjekker at fila DB_CONFIG finnes i hver miljøkatalog, og leser valgene som er i denne fila for bruk med akkurat dette Berkeley-miljøet.

Berkeley-konfigurasjonsfila for ditt depot ligger i miljøkatalogen db i depot/db/DB_CONFIG. Subversion oppretter selv denne fila når den lager resten av depotet. Fila inneholder innledningsvis noen standardvalg sammen med pekere til dokumentasjonen til Berkeley DB som ligger på nettet så du kan lese om hva disse valgene gjør. Du har selvfølgelig også muligheten til å legge til alle valg som Berkeley DB støtter til DB_CONFIG-fila. Pass bare på at mens Subversion aldri prøver å lese eller forstå innholdet i fila og bruker ingen av valgene i den, vil du unngå å gjøre forandringer i konfigurasjonen som får Berkeley DB seg til å oppføre seg annerledes enn det Subversionkoden forventer. I tillegg vil ikke forandringer gjort i DB_CONFIG aktiviseres før du gjenoppretter databasemiljøet (ved bruk av svnadmin recover).

Forrige	Opp	Neste
Det grunnleggende ved et depot	Hjem	Vedlikehold av depotet