Før vi hopper inn i det mer generelle innen emnet depotadministrasjon, la oss definere videre hva et depot er. Hvordan ser det ut? Hvordan føles det? Vil det ha teen sin varm eller med is, søt, og med sitron? Som en administrator blir det forventet av deg at du må forstå sammensetningen av et depot både fra et logisk perspektiv – det å styre med hvordan data er representert i depotet – og fra et fysisk skrue-og-mutter-perspektiv – hvordan et depot ser ut og oppfører seg i sammenheng med verktøy som ikke hører med til Subversion-pakken. Den følgende seksjonen dekker noen av disse grunnleggende konseptene på et høyt nivå.
Konseptmessig sagt er et Subversiondepot en sekvens av trær. Hvert tre er et øyeblikksbilde av hvordan filene og katalogene så ut på et spesielt tidspunkt. Disse øyeblikksbildene er opprettet som et resultat av klientoperasjoner og blir kalt revisjoner.
Hver revisjon begynner livet som et transaksjonstre. Når du gjør en innlegging, bygger en klient en Subversiontransaksjon som avspeiler deres lokale forandringer (pluss eventuelle forandringer som er blitt lagt inn i tillegg til depotet siden begynnelsen av innleggingsprosessen), og instruerer deretter depotet om å lagre dette treet som det neste øyeblikksbildet i sekvensen. Hvis innleggingen lykkes, blir transaksjonen innlemmet i et nytt revisjonstre, og blir tildelt et nytt revisjonsnummer. Hvis innleggingen av en eller annen grunn ikke lykkes, blir transaksjonen ødelagt og klienten informeres om feilen.
Oppdateringer fungerer på en lignende måte. Klienten bygger et midlertidig transaksjonstre som avspeiler tilstanden til arbeidskopien. Depotet sammenligner deretter dette transaksjonstreet med revisjonstreet i den forespurte revisjonen (vanligvis det nyeste, eller “yngste” treet), og sender tilbake informasjon som forteller klienten om hvilke forandringer som er nødvendig for å forandre deres arbeidskopi til et replikat av det aktuelle revisjonstreet. Etter at oppdateringen er fullført, blir den midlertidige transaksjonen slettet.
Bruken av transaksjonstrær er den eneste måten å gjøre permanente forandringer til et depots versjonskontrollerte filsystem. Det er imidlertid viktig å forstå at livløpet til en transaksjon er komplett fleksible. I tilfellet med oppdateringer er transaksjoner midlertidige trær som blir øyeblikkelig ødelagt. I tilfellet med innlegginger blir transaksjoner transformert inn i permanente revisjoner (eller fjernet hvis innleggingen feiler). I tilfelle en generell feil eller programfeil oppstår, er det mulig at en transaksjon kan bli liggende igjen i depotet (uten å påvirke noe som helst, men tar opp diskplass).
I teorien vil kanskje hele arbeidsflytapplikasjoner en gang gi mer nøyaktig kontroll med levetiden til en transaksjon. Det er mulig å tenke seg et system som ved hver transaksjon beregnet på å bli en revisjon blir satt på venting etter at klienten er ferdig med å beskrive sine forandringer til depotet. Dette ville muliggjøre at hver ny innlegging kan bli sett over av noen andre, kanskje en manager eller ledende utvikler, som kan velge å forfremme transaksjonen til en revisjon eller avbryte den.
Transaksjoner og revisjoner i Subversiondepotet kan ha vedlagte egenskaper. Disse egenskapene er generiske “nøkkel-til-verdi”-mappinger, og blir vanligvis brukt til å lagre informasjon om treet som de er vedlagt. Navnene og verdiene til disse egenskapene er lagret i depotets filsystem, sammen med resten av dataene for treet.
Revisjons- og transaksjonsegenskaper er nyttige for å
assosiere informasjon sammen med et tre som ikke er spesifikt
relatert til filene og katalogene i dette treet ― den typen
informasjon som ikke er behandlet av arbeidskopier for klienten.
For eksempel, når en ny innleggingstransaksjon er opprettet i
depotet, legger Subversion en egenskap til denne transaksjonen
kalt svn:date – et tidsmerke som
representerer tidspunktet transaksjonen ble opprettet.
Når innleggingsprosessen er fullført, og transaksjonen blir
forfremmet til en permanent revisjon, har treet også fått en
egenskap for å lagre brukernavnet til revisjonens forfatter
(svn:author) og en egenskap for å lagre
loggmeldingen som hører til denne revisjonen
svn:log.
Revisjons- og transaksjonsegenskaper er
uversjonerte egenskaper – når de blir
modifisert blir den foregående verdien permanent forkastet.
Selv om revisjonstrær er uforanderlige, gjelder ikke dette
egenskapene som er vedlagt disse trærne.
Du kan legge til, fjerne, og modifisere revisjonsegenskaper til
enhver tid i fremtiden.
Hvis du legger inn en ny revisjon og senere finner ut at du la
inn feil informasjon eller skrivefeil i loggmeldingen, kan du
enkelt forandre verdien i svn:log-egenskapen
med en ny, rettet loggmelding.
I Subversion 1.1 er det to valg for å lagre data i et Subversiondepot. En depottype lagrer alt i en Berkeley DB-database; den andre typen lagrer data som ordinære “flate filer” i et tilpasset format. Fordi Subversionutviklere ofte referer til et depot som “det (versjonerte) filsystemet”, har de lagt seg til vanen med å refere til den sistnevnte typen depot som FSFS[28] – en versjonert filsystemimplementasjon som bruker det vanlige filsystemet til operativsystemet for å lagre data.
Når et depot er opprettet, må administratoren bestemme om Berkeley DB eller FSFS skal brukes. Det er fordeler og ulemper med begge to, som vi vil gå gjennom ganske snart. Ingen av de bakenforliggende depotene er mer “offisielle” enn andre, og programmer som aksesserer depotet er beskyttet fra denne implementasjonsdetaljen. Programmer har ingen formening om hvordan depotet lagrer data; de ser bare revisjons- og transaksjonstrær gjennom depotgrensesnittet.
Tabell 5.1, “Sammenligning av datalagring i depoter” inneholder en tabell som gir en oversikt over forskjellene mellom depoter av typen Berkeley DB og FSFS. De neste seksjonene går inn i detalj.
Tabell 5.1. Sammenligning av datalagring i depoter
| Funksjonalitet | Berkeley DB | FSFS |
|---|---|---|
| Følsom for avbrytelser | veldig; krasj og problemer med rettigheter kan etterlate databasen i en “fastkilt” (Engelsk: wedged) tilstand som krever journalførte gjenopprettingsprosedyrer. | ganske ufølsom. |
| Kan brukes fra et ikke-skrivbart medium | nei | ja |
| Plattformuavhengig lagring | nei | ja |
| Brukbar over nettverksfilsystem | nei | ja |
| Depotstørrelse | litt større | litt mindre |
| Skalerbarhet: Antall revisjonstrær | database; ingen problemer | ytelsen på noen eldre filsystemer blir dårligere med tusenvis av elementer i en katalog. |
| Skalerbarhet: Kataloger med mange filer | langsommere | raskere |
| Hastighet: Uthenting av nyeste kode | raskere | langsommere |
| Hastighet: Store innlegginger | langsommere, men arbeidet blir spredt ut over innleggingen | raskere, men forsinkelse i avslutningen kan forårsake tidsavbrudd for klienten. |
| Behandling av grupperettigheter | følsom for problemer med umask; det beste er om den blir aksessert av bare en bruker. | jobber seg rundt problemer med umask |
| Kodemodenhet | i bruk siden 2001 | i bruk siden 2004 |
I den innledende designfasen av Subversion bestemte utviklerne seg for å bruke Berkeley DB av diverse grunner, blant annet dens åpne lisens, transaksjonsstøtte, stabilitet, effektivitet, enkelt grensesnitt, trådsikkerhet, støtte for databasepekere og så videre.
Berkeley DB tilbyr reell støtte for transaksjoner – kanskje dens kraftigste funksjonalitet. Flere prosesser som aksesserer Subversiondepotene dine trenger ikke å tenke på faren ved å rote til hverandres data. Isolasjonen som transaksjonssystemet tilbyr er slik at for enhver operasjon ser Subversions depotkode et statisk bilde av en database – ikke en database som konstant forandres av en annen prosess – og kan foreta avgjørelser basert på dette bildet. Hvis avgjørelsen kommer i konflikt med det en annen prosess gjør, blir hele operasjonen rullet tilbake som om den aldri skjedde, og Subversion prøver forsiktig operasjonen mot et nytt, oppdatert (og fortsatt statisk) bilde av databasen.
En annen fin funksjonalitet med Berkeley DB er varme backuper (hot backups) – muligeten til å ta sikkerhetskopi av databasen uten å ta den ned. Vi vil diskutere hvordan du tar backup av depotet i “Sikkerhetskopi av depotet”, men fordelene med å kunne ta fullstendige fungerende kopier av depotene dine uten nedetid er innlysende.
Berkeley DB er også et veldig sikkert databasesystem. Subversion bruker Berkeley DBs loggefasiliteter, som betyr at databasen først lager en beskrivelse i loggfiler på disken om hva den er i ferd med å gjøre, og foretar deretter selve modifiseringen. Dette er for å forsikre seg om at i tilfelle noe går galt, kan databasesystemet hente tilbake et tidligere sjekkpunkt – en posisjon i loggfilene som den vet ikke er ødelagt – og “spille av” transaksjoner inntil dataene er gjenopprettet til en fungerende tilstand. Se “Bruken av diskplass” for mer angående loggfilene i Berkeley DB.
Men alle roser har torner, og derfor må vi være klar over noen kjente begrensninger i Berkeley DB. For det første er ikke Berkeley DB-miljøer portable. Du kan ikke bare kopiere et Subversiondepot som er laget på et UNIX-system til et Windows-system og forvente at det skal virke. Selv om mye av Berkely DB-formatet er arkitekturuavhengig, er det andre aspekter med miljøet som ikke er det. For det andre bruker Subersion Berkeley DB på en måte som ikke vil fungere i Windows 95/98 – hvis du må ha depotet på en Windowsmaskin, bruk Windows 2000 eller Windows XP. Legg heller aldri et Berkeley DB-depot på en nettverksdisk. Selv om Berkeley DB lover å oppføre seg korrekt på nettverksdisker som oppfyller spesielle kriterier, er det nesten ingen kjente nettverksdelinger som faktisk oppfyller alle disse spesifikasjonene.
Til sist, fordi Berkeley DB er et bibliotek linket direkte
inn i Subversion, er det mer sårbart for avbrudd enn et typisk
relasjonsdatabasesystem.
De fleste SQL-systemer har for eksempel en dedisert
serverprosess som fordeler all tilgang til tabeller.
Hvis et program som aksesserer databasen krasjer av en eller
annen grunn, oppdager daemonen som styrer databasen at
forbindelsen er brutt og ordner opp i eventuelt rot som blir
liggende igjen.
Og fordi databasedaemonen er den eneste prosessen som
aksesserer tabellene, trenger ikke applikasjoner å tenke på
rettighetskonflikter.
Disse tingene er imidlertid ikke tilfelle med Berkeley DB.
Subversion (og programmer som bruker Subversionbiblioteker)
aksesserer databasetabellene direkte, noe som betyr at et
programkrasj kan etterlate databasen i en midlertidig,
utilgjengelig tilstand.
Når dette skjer, må en administrator be Berkeley DB om
gjenoppretting til et sjekkpunkt, noe som er litt plagsomt.
Andre ting kan føre til at et depot “kiler seg
fast”
(“wedge”) sammen
med krasjede prosesser, som for eksempel programmer som kommer
i konflikt angående eierskap og tilgang til databasefilene.
Så mens et Berkeley DB-depot er ganske raskt og skalerbart,
fungerer det best når det kun blir brukt av én enkelt
serverprosess som kjører som én bruker – som for eksempel
Apaches httpd eller
svnserve (se Kapittel 6, Serverkonfigurasjon) – istedenfor å aksessere det med
mange forskjellige brukere via file:///
eller svn+ssh://-URLer.
Hvis et Berkeley DB-depot blir brukt direkte med flere
forskjellige brukere, pass på at du har lest “Støtte for flere metoder for
tilgang til depotet”.
I midten av 2004 ble et nytt lagringsformat for depotet laget, et som ikke bruker en database i det hele tatt. Et FSFS-depot lagrer et revisjonstre i en enkelt fil, og alle depotets revisjoner kan dermed finnes i en enkelt underkatalog full av nummererte filer. Transaksjoner blir opprettet i separate underkataloger. Når den er komplett, blir en enkelt transaksjonsfil opprettet og flyttet til revisjonskatalogen og garanterer dermed at innleggingen blir atomisk. Og fordi en revisjonsfil er permanent og uforanderlig, kan depotet også bli tatt backup av mens det er i bruk, akkurat som et Berkeley DB-depot.
Revisjonsfilformatet representerer en revisjons katalogstruktur, filinnhold og forskjeller i forhold til filer i andre revisjonstrær. Ulikt en Berkeley DB-database, er dette lagringsformatet portabelt mellom forskjellige operativsystemer og er ikke sensitiv ovenfor CPU-arkitektur. Fordi det ikke blir brukt journalfiler eller filer som bruker delt hukommelse, kan depotet trygt aksesseres via et nettverksfilsystem og bli utforsket i et skrivebeskyttet miljø. Mangelen på databaseoverhead betyr også at den samlede depotstørrelsen blir en del mindre.
FSFS har også forskjellige ytelseskarakteristikker. Når en katalog med mange filer legges inn, bruker FSFS en O(N)-algoritme for å legge til poster, mens Berkeley DB bruker en O(N^2)-algoritme for å skrive hele katalogen en gang til. På den annen side skriver FSFS den seneste versjonen av ei fil som en delta (forskjell) mot en tidligere versjon, noe som betyr at det å hente ut det seneste treet er litt langsommere enn å hente fullteksten lagret i en HEAD-revisjon i Berkeley DB. FSFS har også en lengre forsinkelse når en innlegging skal fullføres, noe som i ekstreme tilfeller kan føre til at klienter får et tidsavbrudd under venting på respons.
Men den viktigste forskjellen er FSFSs evne til å ikke bli “fastkilt” hvis noe går galt. Hvis en prosess som bruker en Berkeley DB-database får problemer med rettigheter eller plutselig krasjer, er ikke databasen brukbar før en administrator gjenoppretter den. Hvis det samme skjer med en prosess som bruker et FSFS-depot, blir ikke depotet påvirket i det hele tatt. I verste fall blir bare noen transaksjonsdata liggende igjen.
Det eneste virkelige argumentet mot FSFS er fartstiden det har hatt i forhold til Berkeley DB. Det er ikke like mye brukt og har ikke blitt stresstestet like mye, så derfor er mange av disse antakelsene om hastighet og skalerbarhet nettopp det: Antakelser, basert på gode gjetninger. I teorien lover den en lavere barriere å forsere for nye administratorer og er forventet å skape mindre problemer. I praksis vil bare tiden vise om dette stemmer.