Å vedlikeholde et Subversiondepot kan være en skremmende oppgave, mest på grunn av kompleksiteten som er innebygget i systemer med en bakenforliggende database. Å utføre oppgaven godt handler om å kjenne verktøyene – hva de er, når de skal brukes, og hvordan de brukes. Denne seksjonen vil introdusere deg for administrasjonsverktøy som følger med Subversion, og hvordan få dem til å utføre oppgaver som flytting av depot, oppgraderinger, sikkerhetskopiering og opprydding.
Subversion har en håndfull programmer som er nyttige til å opprette, inspisere, modifisere og reparere depotet ditt. La oss se litt nærmere på hvert av disse verktøyene. Etterpå vil vi gå raskt over noen av de programmene som er inkludert i Berkeley DB-distribusjonen som tilbyr funksjonalitet spesifikk til databasedelen i depotet som ikke Subversions egne verktøy tar seg av.
svnlook er et verktøy som følger med Subversion. Det er beregnet for å utforske de forskjellige revisjonene og transaksjonene i et depot. Ingen deler av dette programmet prøver å forandre depotet – det er et “bare lese”-verktøy. svnlook blir vanligvis brukt av påhakningsskriptene i depotet for å rapportere forandringene som er i ferd med å bli lagt inn (i tilfellet med pre-commit-påhakningen) eller det som nettopp ble lagt inn (i tilfellet med post-commit-påhakningen) i depotet. En depotadministrator kan bruke dette verktøyet for diagnoseformål.
svnlook har en likefrem syntaks:
$ svnlook help
general usage: svnlook SUBCOMMAND REPOS_PATH [ARGS & OPTIONS ...]
Note: any subcommand which takes the '--revision' and '--transaction'
options will, if invoked without one of those options, act on
the repository's youngest revision.
Type "svnlook help <subcommand>" for help on a specific subcommand.
…
Nesten hver eneste av delkommandoene til
svnlook kan operere på enten et revisjons-
eller transaksjonstre og skrive ut informasjon om selve treet
eller hvordan det skiller seg ut fra den forrige revisjonen i
depotet.
Du bruker valgene --revision og
--transaction for å spesifisere henholdsvis
hvilken revisjon eller transaksjon som skal undersøkes.
Legg merke til at mens revisjonsnumre fremstår som naturlige
tall, er transaksjonsnavn alfanumeriske strenger.
Husk at filsystemet bare tillater gjennomgang av transaksjoner
som enda ikke er lagt inn (transaksjoner som ikke har
resultert i en ny revisjon).
De fleste depot vil ikke ha noen slike transaksjoner, fordi
transaksjoner vanligvis enten er lagt inn (som diskvalifiserer
dem fra visning) eller avbrutt og fjernet.
Hvis både valgene --revision og
--transaction mangler, vil
svnlook undersøke den yngste (eller
“HEAD”) revisjonen i depotet.
Så de følgende to kommandoene gjør akkurat det samme når 19 er
den yngste revisjonen i depotet som ligger i
/sti/til/depot:
$ svnlook info /sti/til/depot $ svnlook info /sti/til/depot --revision 19
Det eneste unntaket fra disse reglene om delkommandoer er
svnlook youngest-delkommandoen, som ikke
tar noen valg, og bare skriver ut nummeret for
HEAD-revisjonen.
$ svnlook youngest /sti/til/depot 19
Utdataene fra svnlook er designet for å
være lesbare både for menneske og maskin.
Som et eksempel kan vi ta utdataene fra delkommandoen
info:
$ svnlook info /sti/til/depot sally 2002-11-04 09:29:13 -0600 (Mon, 04 Nov 2002) 27 La til det vanlige greske treet.
Utdataene fra info-delkommandoen er
definert som:
Forfatteren, etterfulgt av linjeslutt.
Datoen, etterfulgt av linjeslutt.
Antallet tegn i loggmeldingen, etterfulgt av linjeslutt.
Selve loggmeldingen, etterfulgt av linjeslutt.
Disse utdataene er leselige for det menneskelige øye, det vil si at elementer som datoen blir vist som tekst istedenfor noe mer obskurt (som antall nanosekunder siden isbilen kjørte forbi). Men disse utdataene er også lesbare for en datamaskin – fordi loggmeldingen kan inneholde flere linjer og ha ubegrenset lengde, skriver svnlook lengden på denne meldingen før selve meldingen. Dette tillater skript og andre programmer som bruker denne kommandoen å gjøre intelligente valg angående loggmeldingen, som hvor mye hukommelse som skal reserveres for meldingen, eller i det minste hvor mange bytes som må hoppes over når disse utdataene ikke er den siste datadelen i strømmen.
En annen vanlig bruk av svnlook er å
faktisk vise innholdet i et revisjons- eller transaksjonstre.
Kommandoen svnlook tree viser katalogene og
filene i det forespurte treet.
Hvis du angir valget --show-ids, vil den også
vise noderevisjons-ID for hver av disse stiene (som vanligvis
er mer nyttige for utviklere enn vanlige brukere).
$ svnlook tree /sti/til/depot --show-ids
/ <0.0.1>
A/ <2.0.1>
B/ <4.0.1>
lambda <5.0.1>
E/ <6.0.1>
alpha <7.0.1>
beta <8.0.1>
F/ <9.0.1>
mu <3.0.1>
C/ <a.0.1>
D/ <b.0.1>
gamma <c.0.1>
G/ <d.0.1>
pi <e.0.1>
rho <f.0.1>
tau <g.0.1>
H/ <h.0.1>
chi <i.0.1>
omega <k.0.1>
psi <j.0.1>
iota <1.0.1>
Når du har sett på layouten for kataloger og filer i treet ditt, kan du bruke kommandoer som svnlook cat, svnlook propget og svnlook proplist for å grave dypere i detaljene om disse filene og katalogene.
svnlook kan utføre en rekke andre forespørsler, vise delsett av biter av informasjon som vi har nevnt tidligere, rapportere hvilke stier som ble modifisert i en gitt revisjon eller transaksjon, vise tekst- og egenskapsforskjeller gjort med filer og kataloger og så videre. Det følgende er en rask beskrivelse av den nåværende listen med delkommandoer som svnlook aksepterer, og utdataene fra disse delkommandoene:
authorSkriv treets forfatter.
catSkriv innholdet av ei fil i treet.
changedList alle filer og kataloger som forandret seg i treet.
dateSkriv dato og klokkeslett for treet.
diffLag unified diff (patch) av forandrede filer.
dirs-changedList katalogene i treet som enten selv forandret seg, eller der en fil under den forandret seg.
historyVis interessante punkter i historien for en versjonert sti (steder der modifiseringer eller kopieringer skjedde).
infoSkriv treets forfatter, tidspunkt, antall tegn i loggmeldingen og selve loggmeldingen.
lockHvis en sti er låst, beskriv låseattributtene.
logVis loggmeldingen for treet.
propgetSkriv verdien for en egenskap på en sti i treet.
proplistSkriv navnene og verdiene til egenskapene satt på stier i treet.
treeSkriv en liste over treet, med valgfri visning av filsystemets noderevisions-IDer som er assosiert med hver sti.
uuidSkriv depotets UUID – Universal Unique IDentifier.
youngestSkriv det yngste revisjonsnummeret.
Programmet svnadmin er depotadministratorens beste venn. Ved siden av å gi muligheten til å opprette Subversiondepoter, tillater dette programmet deg å utføre flere vedlikeholdsoperasjoner på disse depotene. Syntaksen på svnadmin er lik den i svnlook:
$ svnadmin help general usage: svnadmin SUBCOMMAND REPOS_PATH [ARGS & OPTIONS ...] Type "svnadmin help <subcommand>" for help on a specific subcommand. Available subcommands: create deltify dump help (?, h) …
Vi har allerede nevnt delkommandoen
create i svnadmin (se
“Opprettelse og konfigurering av depotet”).
De fleste andre vil vi gå grundigere gjennom senere i dette
kapitlet.
Nå nøyer vi oss med å ta en rask kikk på hva de forskjellige
delkommandoene tilbyr.
createOpprett et nytt Subversiondepot.
deltifyGå over et spesifisert revisjonsområde og utfør
forløper-deltifisering på stiene som forandret seg i
disse revisjonene.
Hvis ingen revisjoner er spesifisert, vil denne
kommandoen rett og slett bare deltifisere
HEAD-revisjonen.
dumpDump innholdet av depotet, begrenset av et spesifisert sett av revisjoner, i et portabelt dumpformat.
hotcopyLag en “varm kopi” av et depot. Du kan kjøre denne kommandoen til enhver tid og lage en trygg kopi av depotet, selv om andre prosesser bruker depotet.
list-dblogs(Bare Berkeley DB-depot.) List stiene for Berkeley DB-loggfiler assosiert med depotet. Denne listen inkluderer alle loggfiler ― de som fortsatt brukes av Subversion, sammen med de som ikke lenger er i bruk.
list-unused-dblogs(Bare Berkeley DB-depot.) List stiene for Berkeley DB-loggfiler assosiert med, men ikke lenger brukt av depotet. Du kan trygt fjerne disse loggfilene fra depotet og muligens arkivere dem for senere bruk i tilfelle du en gang får bruk for katastrofe-gjenoppretting av depotet.
loadLast et sett revisjoner inn i et depot fra en strøm
av data som bruker det samme portable dumpformatet
generert av
dump-delkommandoen.
lslocksList og beskriv enhver lås som eksisterer i depotet.
lstxnsList navnene på Subversiontransaksjonene som ikke er lagt inn, men som eksisterer i depotet.
recoverUtfør gjenoppretting på et depot som trenger det, vanligvis etter at en fatal feil er oppstått som forhindret en prosess fra å lukke kommunikasjonen med depotet på en skikkelig måte.
rmlocksFjern låser fra listede stier betingelsesløst.
rmtxnsFjern Subversiontransaksjoner fra depotet på en
renslig måte (kan bruke utdataene fra
lstxns-delkommandoen).
setlogErstatt den nåværende verdien i
svn:log-egenskapen (loggmelding) for
en angitt revisjon i depotet med en ny verdi.
verifyVerifiser innholdet i et depot. Dette inkluderer blant annet sjekk av kontrollsummer til de versjonerte dataene som er lagret i depotet.
Siden Subversion lagrer alt i et skjult databasesystem, er det å prøve på manuelle forandringer ikke spesielt lurt, for ikke å si vanskelig. Og når dataene er lagret i depotet, har ikke Subversion noen enkel måte å fjerne disse dataene.[29] Men det er ikke til å komme forbi at det er noen ganger du vil manipulere historien til depotet ditt. Det kan være at du vil fjerne alle spor etter ei fil som ble lagt til ved en ulykke (og som av en eller annen grunn ikke skal være der). Eller du har kanskje flere prosjekter som deler et enkelt depot, og du bestemmer deg for å dele dem opp i sine egne depoter. For å utføre oppgaver som dette, trenger administratorer en mer håndterlig og formbar representasjon av dataene i deres egne depot – dumpformatet for Subversiondepot.
Dumpformatet for Subversiondepot er en representasjon av forandringene som du har gjort i dine versjonerte data over tid, i et menneskelig lesbart format. Du bruker kommandoen svnadmin dump for å generere dumpdataene og svnadmin load for å legge disse dataene inn i et nytt depot (se “Flytte et depot”). Den fine tingen med det menneskelesbare dumpformatet er at du kan inspisere og modifisere det hvis du er forsiktig. Selvfølgelig, bakdelen er at hvis du har to år med depotaktivitet pakket inn i en stor dumpfil, vil det ta deg lang, lang tid å manuelt inspisere og modifisere den.
Selv om det ikke vil være det vanligste verktøyet til bruk for depotadministratoren, gir svndumpfilter en veldig spesiell type nyttig funksjonalitet – muligheten til å raskt og enkelt modifisere disse dumpdataene ved å fungere som et stibasert filter. Du gir ganske enkelt programmet en liste over stier som du vil beholde, eller en liste med stier som du vil fjerne, og sender deretter dumpdataene fra depotet via et rør gjennom dette filteret. Resultatet er en modifisert strøm av dumpdata som kun inneholder de versjonerte stiene som du (eksplisitt eller implisitt) ba om.
Syntaksen for svndumpfilter er som følger:
$ svndumpfilter help general usage: svndumpfilter SUBCOMMAND [ARGS & OPTIONS ...] Type "svndumpfilter help <subcommand>" for help on a specific subcommand. Available subcommands: exclude include help (?, h)
Her er det bare to interessante delkommandoer. De gir deg valget mellom eksplisitt eller implisitt inkludering av stier i strømmen:
excludeFiltrer bort et sett med stier fra dumpdatastrømmen.
includeTillat bare de angitte stiene å slippe gjennom dumpdatastrømmen.
La oss se på et realistisk eksempel på hvordan du vil bruke dette programmet. Vi diskuterer en annen plass (se “Velge en depot-layout”) prosessen med å bestemme hvordan dataene i depotene dine skal legges opp – om du vil bruke ett depot for hvert prosjekt eller kombinere dem, hvordan du arrangerer ting innenfor depotet og så videre. Men noen ganger etter at nye revisjoner begynner å komme inn, tenker du på nytt over layouten og vil gjøre noen forandringer. En vanlig forandring er å bestemme seg for å flytte flere prosjekter som deler et enkelt depot inn i separate depot for hvert prosjekt.
Vårt hypotetiske depot inneholder tre prosjekter:
calc,
calendar og spreadsheet.
De har levd ved siden av hverandre som følger:
/
calc/
trunk/
branches/
tags/
calendar/
trunk/
branches/
tags/
spreadsheet/
trunk/
branches/
tags/
For å få disse tre prosjektene inn i deres egne depot, dumper vi først hele depotet:
$ svnadmin dump /path/to/repos > depot-dumpfil * Dumped revision 0. * Dumped revision 1. * Dumped revision 2. * Dumped revision 3. … $
Så kjører vi denne dumpfila gjennom filteret og for hver gang inkluderer vi bare en av katalogene på toppnivå, noe som resulterer i tre nye dumpfiler:
$ cat depot-dumpfil | svndumpfilter include calc > calc-dumpfil … $ cat depot-dumpfil | svndumpfilter include calendar > cal-dumpfil … $ cat depot-dumpfil | svndumpfilter include spreadsheet > ss-dumpfil … $
På dette punktet må du ta en avgjørelse.
Hver av dumpfilene fine vil lage et gyldig depot, men vil
gjenskape stiene nøyaktig som de var i det opprinnelige
depotet.
Dette betyr at selv om du vil ha et depot kun for
calc-prosjektet, vil dette depotet fortsatt
ha en toppkatalog kalt calc.
Hvis du vil at katalogene trunk,
tags og branches
skal være i roten av depotet, vil du kanskje ønske å redigere
dumpfilene og forandre Node-path og
Node-copyfrom-path i headerne så de ikke
lengre inneholder denne calc/-komponenten
i stien.
I tillegg ønsker du å fjerne seksjonen i dumpdataene som
oppretter calc-katalogen.
Det vil se ut omtrent som dette:
Node-path: calc Node-action: add Node-kind: dir Content-length: 0
Hvis du planlegger å redigere dumpfila manuelt for å fjerne en toppkatalog, vær sikker på at tekstbehandleren din ikke er satt til å automatisk konvertere linjeslutt til det lokale formatet (det vil si \r\n til \n). Dette vil føre til at innholdet ikke vil samsvare med metadataene og dumpfila vil dermed bli ubrukelig.
Alt som gjenstår nå er å opprette dine tre nye depot og laste hver dumpfil inn i det riktige depotet:
$ svnadmin create calc; svnadmin load calc < calc-dumpfil
<<< Started new transaction, based on original revision 1
* adding path : Makefile ... done.
* adding path : button.c ... done.
…
$ svnadmin create calendar; svnadmin load calendar < cal-dumpfil
<<< Started new transaction, based on original revision 1
* adding path : Makefile ... done.
* adding path : cal.c ... done.
…
$ svnadmin create spreadsheet; svnadmin load spreadsheet < ss-dumpfil
<<< Started new transaction, based on original revision 1
* adding path : Makefile ... done.
* adding path : ss.c ... done.
…
$
Begge delkommandoene til svndumpfilter godtar valg for å bestemme hva de skal gjøre med “tomme” revisjoner. Hvis en gitt revisjon bare inneholdt forandringer i stier som ble filtrert bort kan denne revisjonen som nå er tom bli betraktet som uinteressant eller til og med uønsket. Så for å gi brukeren kontroll over hva som skal gjøres med disse revisjonene, har svndumpfilter disse kommandolinjevalgene:
--drop-empty-revsIkke lag tomme revisjoner i det hele tatt – utelat dem.
--renumber-revsHvis tomme revisjoner er droppet (ved bruk av valget
--drop-empty-revs), forandres
revisjonsnumrene på de gjenværende revisjonene så det
ikke blir mellomrom i den numeriske sekvensen.
--preserve-revpropsHvis tomme revisjoner ikke droppes, ta vare på revisjonsegenskaper (loggmelding, forfatter, dato, egendefinerte egenskaper og så videre) for disse tomme revisjonene. Tomme revisjoner vil ellers bare inneholde det originale tidspunktet og en generert loggmelding som indikerer at denne revisjonen ble tømt av svndumpfilter.
Selv om svndumpfilter kan være veldig
nyttig og sparer masse tid, er det dessverre et par ting å
passe på.
For det første er dette verktøyet overfølsom for sti-semantikk.
Legg merke til om stiene i dumpfila er spesifisert med eller
uten skråstreker i starten.
Dette vil du se i Node-path og
Node-copyfrom-path i headerne.
… Node-path: spreadsheet/Makefile …
Hvis stiene har innledende skråstreker, skal du også ha innledende skråstreker i stiene som du leverer til svndumpfilter include og svndumpfilter exclude (og hvis de ikke har det, skal du ikke gjøre det). Videre, hvis dumpfila di har inkonsekvent bruk av innledende skråstreker av en eller annen grunn,[30] bør du normalisere disse stiene så de alle enten har eller mangler innledende skråstreker.
I tillegg kan kopierte stier gi deg litt trøbbel. Subversion støtter kopioperasjoner i depotet, der en ny sti blir opprettet ved å kopiere en allerede eksisterende sti. Det er mulig at på et eller annet punkt i livsløpet til depotet blir ei fil eller katalog kopiert fra en plass som svndumpfilter utelater, til en plass som programmet inkluderer. For å gjøre dumpdataene selvforsynt, må svndumpfilter vise tilleggingen av den nye stien – inkludert innholdet av alle filer opprettet av kopieringen – og ikke vise denne tilleggingen som en kopiering fra en kilde som ikke eksisterer i den filtrerte dumpdatastrømmen. Men fordi dumpformatet i Subversion bare viser hva som ble forandret i hver revisjon, kan det være at innholdet i kilden for kopien ikke er tilgjengelig. Hvis du har mistanke om at du har denslags kopier i depotet ditt, vil du kanskje tenke gjennom valget ditt av inkluderte/utelatte stier på nytt.
Hvis du bruker et Berkeley DB-depot, vil alle strukturer
og data være i et sett med databasetabeller i katalogen
db i depotet ditt.
Denne underkatalogen er en vanlig Berkeley DB miljøkatalog, og
kan derfor bli brukt i forbindelse med alle Berkeley
databaseverktøy (du kan se dokumentasjonen for disse
verktøyene på Sleepycats hjemmeside, http://www.sleepycat.com/).
For daglig Subversionbruk er disse verktøyene unødvendige. Mesteparten av funksjonaliteten som vanligvis er nødvendig for Subversiondepot er blitt duplisert i svnadmin-verktøyet. For eksempel, svnadmin list-unused-dblogs og svnadmin list-dblogs utfører en del av hva Berkeley-kommandoen db_archive gjør, og svnadmin recover gjenspeiler de vanlige bruksmåter for db_recover-programmet.
Det er fortsatt noen få Berkeley DB-programmer som du kan finne nyttige. Programmene db_dump og db_load skriver og leser henholdsvis et tilpasset filformat som beskriver nøkler og verdier i en Berkeley DB-database. Siden Berkeley DB-databaser ikke er portable på tvers av maskinarkitekturer, er dette formatet en nyttig måte å overføre disse databasene fra maskin til maskin, uavhengig av arkitektur eller operativsystem. I tillegg kan programmet db_stat gi deg nyttig informasjon om statusen til Berkeley DB-miljøet, inkludert detaljert statistikk om undersystemer som tar seg av låsing og lagring.
Subversiondepotet ditt vil vanligvis kreve veldig lite tilsyn når det er konfigurert sånn som du vil ha det. Det er imidlertid enkelte ganger en administrator må trå til med manuell assistanse. Verktøyet svnadmin gir nyttig funksjonalitet for å hjelpe deg med å utføre oppgaver som:
modifisere loggmeldinger
fjerne døde transaksjoner
gjenopprette “fastkilte” depoter, og
flytte depotinnholdet til et annet depot.
Den delkommandoen som kanskje blir brukt mest i
svnadmin er setlog.
Når en transaksjon er lagt inn i depotet og forfremmet til en
revisjon, blir den beskrivende loggmeldingen assosiert med denne
nye revisjonen lagret som en uversjonert egenskap vedlagt selve
revisjonen.
Med andre ord, depotet husker bare den seneste verdien til
egenskapen, og forkaster tidligere versjoner.
Noen ganger skjer det at det blir feil i en loggmelding (en
skrivefeil eller kanskje noe feilinformasjon).
Hvis depotet er satt opp (ved bruk av påhakningene
pre-rev-prop-change og
post-revprop-change; se “Påhakningsskript”) til å akseptere
forandringer i denne loggmeldingen etter at innleggingen er
ferdig, kan brukeren “fikse” loggmeldingen fra en annen maskin ved bruk av
svn-programmets
propset-kommando (se Kapittel 9, Subversion Complete Reference).
Men fordi det her er en potensiell sjanse for å miste
informasjon for alltid, er standard oppsett på et
Subversiondepot å ikke godta forandringer i uversjonerte
egenskaper – unntatt av en administrator.
Hvis en loggmelding må forandres av en administrator, kan
dette gjøres ved å bruke svnadmin setlog.
Denne kommandoen forandrer loggmeldingen
(svn:log-egenskapen) på en gitt revisjoen i
et depot, ved å lese den nye verdien fra ei fil.
$ echo "Her er den nye, korrekte loggmeldingen" > nylogg.txt $ svnadmin setlog mittdepot nylogg.txt -r 388
Kommandoen svnadmin setlog alene er
fortsatt bundet av den samme beskyttelsen mot å modifisere
uversjonerte egenskaper som en klient på en annen maskin er –
påhakningsskriptene pre-revprop-change og
post-revprop-change blir fortsatt aktivisert
og må derfor settes opp til å godta denne typen forandringer.
Men en administrator kan gå rundt denne beskyttelsen ved å angi
valget --bypass-hooks til svnadmin
setlog-kommandoen.
Men husk at ved å omgå påhakningsskriptene unngår du også utføring av ting som meldinger via email om forandringer i egenskaper, backupsystemer som følger med på egenskapsforandringer og så videre. Med andre ord, vær meget forsiktig med hva du forandrer og hvordan du forandrer det.
En annen vanlig måte å bruke svnadmin på er å spørre depotet om utestående – muligens døde – Subversiontransaksjoner. Hvis en innlegging feiler, blir transaksjonen vanligvis ryddet opp i. Det vil si, selve transaksjonen blir fjernet fra depotet, og alle dataene assosiert med (og bare med) denne transaksjonen blir fjernet i samme slengen. Men enkelte ganger kan det skje en feil på en måte som gjør at oppryddingen av transaksjonen aldri skjer. Dette kan skje av flere grunner: Kanskje ble klientoperasjonen uelegant avsluttet av brukeren, eller en nettverksfeil kan ha skjedd midt i en operasjon og så videre. Uansett grunnen, døde transaksjoner kan skje. De gjør ingen reell skade utenom å okkupere en liten del av diskplassen, og en pertentlig administrator vil nok ønske å fjerne dem.
Du kan bruke svnadmins
lstxns-kommando for å liste navnene på
utestående transaksjoner som ligger i depotet for
øyeblikket.
$ svnadmin lstxns mittdepot 19 3a1 a45 $
Hvert element i de resulterende utdataene kan deretter bli
brukt sammen med svnlook (og dens valg
--transaction) for å finne ut hvem som lagde
transaksjonen, når den ble laget, hvilke typer forandringer som
ble gjort i transaksjonen – med andre ord, om transaksjonen er
eller ikke er en trygg kandidat for sletting!
Hvis den er det, kan transaksjonens navn leveres til
svnadmin rmtxns som vil utføre fjerning av
transaksjonen.
rmtxns-delkommandoen kan faktisk motta
dataene direkte fra det som lstxns
genererer!
$ svnadmin rmtxns mittdepot `svnadmin lstxns mittdepot` $
Hvis du bruker disse to delkommandoene som dette, bør du vurdere å gjøre depotet midlertidig utilgjengelig for klienter. På denne måten kan ingen starte på en legitim transaksjon før du starter på opprenskningen. Det følgende er en skallsnutt som raskt kan generere informasjon om hver utestående transaksjon i depotet ditt:
Eksempel 5.1. txn-info.sh (Rapporterer utestående transaksjoner)
#!/bin/sh
### Generer informasjon om alle utestående transaksjoner i et
### Subversiondepot.
REPOS="${1}"
if [ "x$REPOS" = x ] ; then
echo "bruk: $0 STI_TIL_DEPOT"
exit
fi
for TXN in `svnadmin lstxns ${REPOS}`; do
echo "---[ Transaksjon ${TXN} ]-------------------------------------------"
svnlook info "${REPOS}" --transaction "${TXN}"
done
Du kan kjøre det foregående skriptet ved å bruke /sti/til/txn-info.sh /sti/til/depot. Utdataene er hovedsaklig flere biter av utdataene fra svnlook info som er satt sammen (se “svnlook”), og vil se ut som noe i denne retningen:
$ txn-info.sh mittdepot ---[ Transaksjon 19 ]------------------------------------------- sally 2001-09-04 11:57:19 -0500 (Tue, 04 Sep 2001) 0 ---[ Transaksjon 3a1 ]------------------------------------------- harry 2001-09-10 16:50:30 -0500 (Mon, 10 Sep 2001) 39 Prøver å legge inn over et skrøpelig nettverk. ---[ Transaksjon a45 ]------------------------------------------- sally 2001-09-12 11:09:28 -0500 (Wed, 12 Sep 2001) 0 $
En transaksjon som har vært avbrutt over lengre tid representerer vanligvis en feilet eller avbrutt innlegging. Tidspunktet til en transaksjon kan bidra med interessant informasjon – for eksempel, hvor sannsynlig er det at en operasjon som begynte for ni måneder siden fortsatt er aktiv?
Kort sagt er det ikke nødvendig å foreta ukloke beslutninger angående fjerning av transaksjoner. Forskjellige kilder til informasjon – inkludert Apaches feil- og adgangslogg, loggene med gjennomførte Subversioninnlegginger og så videre – kan bli tatt med i beslutningsprosessen. Til sist kan administratoren rett og slett kommunisere med eieren av en tilsynelatende død transaksjon (via email, for eksempel) for å fastslå om transaksjonen faktisk er i en zombietilstand.
Selv om prisen på datalagring har stupt de siste årene, er bruken av diskplass fortsatt noe administratorer må tenke på hvis de vil versjonere store mengder data. Hver eneste ekstra byte konsumert av det aktive depotet er en byte som må tas backup av utenfor maskinen, kanskje flere ganger som del av roterende backuper. Hvis du bruker et Berkeley DB-depot, er den primære lagringsmekanismen et komplekst databasesystem og det er nyttig å vite hvilke deler av dataene som må forbli på den aktive siten, hvilke som det må tas sikkerhetskopi av, og hva som trygt kan fjernes. Denne seksjonen handler spesifikt om Berkeley DB, FSFS-depot har ingen ekstra data som kan ryddes opp i eller brukes om igjen.
Inntil nylig var de største synderne når det gjelder diskplass som brukes av Subversiondepoter loggfilene der Berkeley DB utfører skrivingen på forhånd før de aktuelle databasefilene modifiseres. Disse filene inneholder alle operasjonene som blir utført når databasen skal forandres fra en tilstand til en annen – mens databasefilene til enhver tid avspeiler en viss tilstand, inneholder loggfilene alle de mange småforandringene langs veien mellom tilstander. Derfor kan de øke i omfang ganske fort.
Heldigvis, fra og med 4.2-versjonen av Berkeley DB har
databasemiljøet muligheten til å fjerne sine egne ubrukte
loggfiler uten eksterne prosedyrer.
Ethvert depot som er laget med en svnadmin
som er kompilert mot Berkeley DB 4.2 eller større vil bli
konfigurert for denne automatiske slettingen av loggfiler.
Hvis du ikke vil ha denne funksjonaliteten aktivisert, kan du
ganske enkelt angi valget --bdb-log-keep til
svnadmin create-kommandoen.
Hvis du glemmer å gjøre dette, eller forandrer mening på et
senere tidspunkt, kan du redigere fila
DB_CONFIG som ligger i katalogen
db i depotet.
Du kommenterer bort linjen som inneholder direktivet
set_flags DB_LOG_AUTOREMOVE og kjører
deretter svnadmin recover på depotet ditt
for å aktivisere forandringene i konfigrasjonen.
Se “Konfigurasjon av Berkeley DB” for mer
informasjon om databasekonfigurasjon.
Uten noen form for automatisk sletting av loggfiler på plass, vil loggfilene samle seg opp etterhvert som du bruker depotet. Dette er faktisk en form for God Ting i databasesystemet – du vil være i stand til å gjenopprette hele databasen ved bruk av loggfilene alene, så disse filene kan være nyttige for gjenoppretting etter en katastrofe. Men vanligvis vil du arkivere loggfilene som ikke lenger er i bruk av Berkeley DB og deretter fjerne dem fra disken for å spare plass. Bruk kommandoen svnadmin list-unused-dblogs for å liste ut de ubrukte loggfilene:
$ svnadmin list-unused-dblogs /sti/til/depot /sti/til/depot/log.0000000031 /sti/til/depot/log.0000000032 /sti/til/depot/log.0000000033 $ svnadmin list-unused-dblogs /sti/til/depot | xargs rm ## diskplassen er frigjort!
For å holde størrelsen på depotet så liten som mulig, bruker Subversion deltifisering (eller “deltifisert lagring”) inne i selve depotet. Deltifisering involverer å kode representasjonen av en porsjon data som en samling av forskjeller mot en annen porsjon data. Hvis de to delene med data er veldig like, resulterer denne deltifiseringen i sparing av lagringsplass for den deltifiserte porsjonen – istedenfor å ta opp plass lik størrelsen av de originale dataene, brukes nå nok plass for å si: “Jeg ser ut akkurat som de dataene der borte, unntatt de følgende forandringene”. Mer spesifikt, hver gang en ny versjon av ei fil blir lagt inn i depotet, koder Subversion den forrige versjonen (egentlig flere tidligere versjoner) som en delta mot den nye versjonen. Resultatet er at mesteparten av depotdataene som har en tendens til å forandre seg i størrelse – innholdet av versjonerte filer – blir lagret med en mye mindre datamengde enn den originale “fulltekst”-representasjonen av disse dataene.
Fordi alle Subversions depotdata som blir deltifisert blir lagret i en enkelt Berkeley DB-databasefil, vil ikke nødvendigvis det å redusere størrelsen på de lagrede verdiene nødvendigvis redusere størrelsen på selve databasefila. Berkeley DB vil imidlertid ha interne poster med ubrukte områder i databasefila, og vil bruke disse områdene først før den øker størrelsen på databasefila. Så selv om deltifisering ikke medfører øyeblikkelig sparing av diskplass, kan det redusere fremtidig økning i databasestørrelsen ganske drastisk.
Som nevnt i “Berkeley DB”, kan et Berkeley DB-depot noen ganger bli etterlatt i en frosset tilstand hvis det ikke blir skikkelig lukket. Når dette skjer, må en administrator rulle databasen tilbake i funksjonell stand.
For å beskytte dataene i depotet ditt, bruker Berkeley DB en låsemekanisme. Denne mekanismen forsikrer at deler av databasen ikke blir oppdatert samtidig av flere sin aksesserer databasen, og at hver prosess ser dataene i den korrekte tilstanden som da disse dataene ble lest fra databasen. Når en prosess må forandre noe i databasen sjekker den først om det eksisterer en lås på måldataene. Hvis dataene ikke er låst, låser denne prosessen dataene, gjør forandringene som den ønsker å gjøre, og låser deretter opp dataene. Andre prosesser blir tvunget til å vente inntil denne låsen er fjernet før de får lov til å fortsette med tilgangen til denne seksjonen av databasen. (Dette har ingenting å gjøre med de låsene som du, brukeren, kan bruke på versjonerte filer i depotet; se Three meanings of “lock” for mer informasjon.)
Under bruk av Subversiondepotet kan fatale feil (som å gå tom for diskplass eller tilgjengelig hukommelse) eller avbrytelser forhindre en prosess fra å fjerne låsene som den har plassert i databasen. Resultatet er at det bakenforliggende databasesystemet blir “fastkilt”. Når dette skjer, vil ethvert forsøk på å aksessere depotet henge til evig tid (siden hver ny tilgang vil vente på at en lås skal forsvinne – noe som ikke kommer til å skje).
For det første, hvis dette skjer med depotet ditt, ingen panikk. Berkeley DB-filsystemet benytter seg av databasetransaksjoner og sjekkpunkter og forhåndsskriver journaler for å forsikre at bare de mest katastrofale hendelser[31] kan ødelegge databasen permanent. En tilstrekkelig paranoid depotadministrator vil ta sikkerhetskopier av depotet til en annen maskin på en eller annen måte, men ikke få systemadministratoren din til å hente tilbake det som er på backuptapen helt enda.
For det andre, bruk den følgende oppskriften for å forsøke å “fjerne fastkilingen” av depotet:
Sjekk at det ikker er noen prosesser som aksesserer (eller forsøker å få tilgang) til depotet. For depot på nettverket betyr dette at Apache HTTP også må kjøres ned.
Bli brukeren som eier og vedlikeholder depotet. Dette er viktig fordi en gjenoppretting av depotet med gal bruker kan forandre rettighetene på filene i depotet så det fortsatt vil være utilgjengelig selv etter at det er “reparert”.
Kjør kommandoen svnadmin recover /sti/til/depot. Du vil nå se noe i likhet med dette:
Repository lock acquired. Please wait; recovering the repository may take some time... Recovery completed. The latest repos revision is 19.
Denne kommandoen kan ta flere minutter å fullføre.
Start Subversionserveren på nytt.
Denne prosedyren reparerer nesten ethvert tilfelle av låste
databaser.
Pass på at du kjører denne kommandoen som brukeren som eier og
vedlikeholder databasen, ikke bare som root.
Deler av gjenopprettingsprosessen kan føre til at diverse
databasefiler blir opprettet på nytt (delte områder av
hukommelsen, for eksempel).
Gjenoppretting som root vil lage disse filene
som om de er eid av root, noe som betyr at
til og med etter at du setter opp forbindelsen til databasen
igjen, klarer ikke vanlige brukere å få tilgang til den.
Hvis den nevnte prosedyren av en eller annen grunn ikke
klarer å reparere depotet ditt, skal du gjøre to ting.
Først flytter du det ødelagte depotet ut av veien og legger inn
den siste sikkerhetskopien av den.
Deretter, send en email til Subversionbrukerlisten (på
<users@subversion.tigris.org>) der du beskriver
problemet i detalj.
Dataintegritet har ekstremt høy prioritet for
Subversionutviklerne.
Et Subversionfilsystem har dataene sine spredt over flere
databasetabeller på en måte som generelt bare er forstått av (og
som bare har interesse for) selve Subversionutviklerne.
Ting kan imidlertid skje som gjør at alt eller litt av disse
dataene må samles i et enkeltstående og portabelt
“flatt” filformat.
Subversion har en slik mekanisme, implementert som et par
svnadmin-delkommandoer:
dump og load.
Den vanligste grunnen til å dumpe og laste et Subversiondepot er på grunn av forandringer i selve Subversion. Etterhvert som Subversion modnes, skjer det noen ganger at det blir gjort forandringer i det bakenforliggende databaseoppsettet som fører til at Subversion blir inkompatibel med tidligere versjoner av depotet. Andre grunner for dumping og lasting kan være å flytte et Berkeley DB-depot til et annet operativsystem eller en annen CPU-arkitektur, eller for å bytte mellom Berkeley DB- og FSFS-lagringsformat. Den anbefalte måten å gjøre dette på er relativt enkel:
Bruk din nåværende versjon av svnadmin, dump depotene dine til dumpfiler.
Oppgrader til den nye versjonen av Subversion.
Flytt de gamle depotene ut av veien, og opprett nye på plassen deres ved å bruke den nye versjonen av svnadmin.
Så laster du dumpfilene inn i de respektive nyopprettede depotene ved å bruke den nye versjonen av svnadmin.
Pass på å kopiere alle egne tilpasninger fra de gamle
depotene til de nye, inkludert
DB_CONFIG-filer og påhakningsskript.
Det kan være lurt å lese hva som er forandret i den nye
versjonen av Subversion for å se om det er noen forandringer
der som gjør at du må gjøre forandringer i
påhakningsskriptene eller konfigurasjonen.
Hvis flytteprosessen gjør depotet ditt tilgjengelig på en annen URL (for eksempel flyttet til en annen maskin eller blir aksessert på en annen måte), bør du be alle brukerne dine om å kjøre svn switch --relocate på sine eksisterende arbeidskopier. Se svn switch.
svnadmin dump vil generere utdata med en
rekke depotrevisjoner som er i Subversions spesiallagde
filsystemdumpformat.
Dumpformatet sendes til standard ut-strømmen
(stdout), mens informative meldinger sendes
til standardfeil-strømmen (stderr).
Dette gjør at du kan omdirigere utdatastrømmen til ei fil mens
du holder øye med statusen i terminalvinduet.
$ svnlook youngest mittdepot 26 $ svnadmin dump mittdepot > dumpfil * Dumped revision 0. * Dumped revision 1. * Dumped revision 2. … * Dumped revision 25. * Dumped revision 26.
Når denne prosessen er ferdig, vil du ha en enkelt fil
(dumpfil i det foregående eksempelet) som
inneholder alle dataene som er lagret i depotet ditt i det
forespurte området med revisjoner.
Legg merke til at svnadmin dump leser
revisjonstrær fra depotet akkurat som enhver annen leseprosess
ville gjort det (svn checkout, for eksempel),
så det er trygt å kjøre denne kommandoen når som helst.
Den andre delkommandoen i dette radarparet, svnadmin load, tolker inndatastrømmen som en Subversiondumpfil og “spiller av” disse dumpede revisjonene inn i måldepotet for denne operasjonen. Den gir også informativ feedback, denne gangen ved å bruke standard ut-strømmen:
$ svnadmin load newrepos < dumpfile
<<< Started new txn, based on original revision 1
* adding path : A ... done.
* adding path : A/B ... done.
…
------- Committed new rev 1 (loaded from original rev 1) >>>
<<< Started new txn, based on original revision 2
* editing path : A/mu ... done.
* editing path : A/D/G/rho ... done.
------- Committed new rev 2 (loaded from original rev 2) >>>
…
<<< Started new txn, based on original revision 25
* editing path : A/D/gamma ... done.
------- Committed new rev 25 (loaded from original rev 25) >>>
<<< Started new txn, based on original revision 26
* adding path : A/Z/zeta ... done.
* editing path : A/mu ... done.
------- Committed new rev 26 (loaded from original rev 26) >>>
Resultatet av en lasting er at nye revisjoner blir lagt til
et depot – det samme som skjer når du legger inn revisjoner i
depotet fra en vanlig Subversionklient.
Og akkurat som i en innlegging kan du bruke påhakningsskript for
å utføre oppgaver før og etter hver av innleggingene som blir
gjort under en lasteprosess.
Ved å angi valgene --use-pre-commit-hook og
--use-post-commit-hook sammen med
svnadmin load, kan du instruere Subversion
til å utføre henholdsvis pre-commit- og post-commit-skriptene
for hver lastede revisjon.
Du kan for eksempel bruke disse til å forsikre deg om at de
lastede revisjonene går gjennom de samme valideringsstegene som
vanlige innlegginger går gjennom.
Selvfølgelig bør du bruke disse valgene med forsiktighet – hvis
post-commit-påhakningen sender epost til en postliste for hver
ny revisjon, vil du nok ikke sende ut hundre- eller tusenvis av
innleggingsmeldinger i rask rekkefølge til denne listen for hver
eneste lastede revisjon!
Du kan lese mer om bruken av påhakningsskript i “Påhakningsskript”.
Legg merke til at fordi svnadmin bruker standard inn- og standard ut-strømmer for depotdumpen og lasteprosessen, kan folk som vet hva de driver på med prøve på ting som dette (kanskje til og med bruke forskjellige versjoner av svnadmin på hver side av røret):
$ svnadmin create nyttdepot $ svnadmin dump mittdepot | svnadmin load nyttdepot
Vanligvis vil dumpfila bli ganske stor – mye
større enn selve depotet.
Dette er fordi hver eneste versjon av hver fil blir representert
som fulltekst i dumpfila.
Dette er den raskeste og enkleste oppførselen, og fin hvis du
sender dumpdataene gjennom et rør direkte til en annen prosess
(som for eksempel et pakkeprogram, filterprogram eller inn i en
lasteprosess).
Men hvis du lager en dumpfil som er ment for langtidslagring,
vil du nok ønske å spare diskplass ved å bruke valget
--deltas.
Med dette valget vil etterfølgende revisjoner av filer bli
generert som pakkede, binære forskjeller – akkurat som
filrevisjoner er lagret i et depot.
Dette valget er langsommere, men resulterer i en dumpfil mer lik
størrelsen til det originale depotet.
Vi nevnte tidligere at svnadmin dump
sender en rekke revisjoner til standard ut.
Bruk --revision-valget for å spesifisere en
enkelt revisjon som skal dumpes, eller et område med revisjoner.
Hvis du utelater dette valget, vil alle eksisterende
depotrevisjoner bli dumpet.
$ svnadmin dump mittdepot --revision 23 > rev-23.dumpfil $ svnadmin dump mittdepot --revision 100:200 > rev-100-200.dumpfil
Når Subversion dumper hver ny revisjon, lagres akkurat nok informasjon til at et framtidig lasteprogram kan gjenskape denne revisjonen basert på en tidligere revisjon. Med andre ord, for enhver gitt revisjon i dumpfila vil bare de elementene som ble forandret i den revisjonen havne i dumpen. Det eneste unntaket fra denne regelen er den første revisjonen som blir dumpet med den nåværende svnadmin dump-kommandoen.
Vanligvis vil Subversion ikke uttrykke den første dumpede revisjonen bare som forskjeller som skal legges til den forrige revisjonen. En grunn til dette er at det ikke er noen tidligere revisjon i dumpfila! For det andre kan ikke Subversion vite tilstanden til depotet som dumpdataene vil bli lastet inn i (hvis det i det hele tatt noen gang blir et). For å garantere at utdataene etter hver kjøring av svnadmin dump er selvforsynt, er den første dumpede revisjonen vanligvis en full representasjon av hver katalog, fil og egenskap i denne revisjonen i depotet.
Denne standardoppførselen kan du imidlertid forandre.
Hvis du legger til --incremental-valget når du
dumper depotet ditt, vil svnadmin sammenligne
den første dumpede revisjonen mot den forrige revisjonen i
depotet, på den samme måten som den behandler alle andre
revisjoner som blir dumpet.
Programmet vil deretter generere den første revisjonen nøyaktig
som det gjør med resten av revisjonene i dumpområdet – det tar
bare med de forandringene som oppsto i den revisjonen.
Fordelen med dette er at du kan lage flere små dumpfiler som kan
bli lastet etter hverandre istedenfor en stor fil.
Dette gjøres på denne måten:
$ svnadmin dump mittdepot --revision 0:1000 > dumpfil1 $ svnadmin dump mittdepot --revision 1001:2000 --incremental > dumpfil2 $ svnadmin dump mittdepot --revision 2001:3000 --incremental > dumpfil3
Disse dumpfilene kan så bli lastet inn i et nytt depot med den følgende kommandosekvensen:
$ svnadmin load nyttdepot < dumpfil1 $ svnadmin load nyttdepot < dumpfil2 $ svnadmin load nyttdepot < dumpfil3
Et annet lurt triks du kan utføre med dette
--incremental-valget går ut å legge til en
rekke revisjoner til en eksisterende dumpfil.
For eksempel kan du ha en
post-commit-påhakning som rett og slett
legger til depotdumpen av den spesifikke revisjonen som utførte
påhakningsskriptet.
Eller du kan ha et skript som kjøres om natten for å legge til
dumpdata for alle revisjonene som ble lagt til depotet siden
forrige gang skriptet ble kjørt.
Brukt på denne måten kan dump- og
load-kommandoen til
svnadmin tilby verdifull hjelp med å ta
sikkerhetskopi av forandringer i depotet over tid i tilfelle
systemkrasj eller andre katastrofer.
Dumpformatet kan også brukes til å flette innholdet av flere
forskjellige depot inn i et enkelt depot.
Ved å bruke valget --parent-dir når du kjører
svnadmin load, kan du spesifisere en ny
virtuell rotkatalog for lasteprosessen.
Dette betyr at hvis du har dumpfiler for tre depoter, la oss si
tekst-dumpfil,
kalender-dumpfil og
regneark-dumpfil, kan du først opprette et
nytt depot som skal inneholde alle sammen:
$ svnadmin create /sti/til/prosjekter $
Deretter, lag nye kataloger i depotet som vil “pakke inn” innholdet av hver av de tre foregående depotene:
$ svn mkdir -m "Opprettet røtter for prosjektene" \
file:///sti/til/prosjekter/tekst \
file:///sti/til/prosjekter/kalender \
file:///sti/til/prosjekter/regneark
Committed revision 1.
$
Til sist, last de individuelle dumpfilene inn i deres respektive plasseringer i det nye depotet:
$ svnadmin load /sti/til/prosjekter --parent-dir tekst < tekst-dumpfil … $ svnadmin load /sti/til/prosjekter --parent-dir kalender < kalender-dumpfil … $ svnadmin load /sti/til/prosjekter --parent-dir regneark < regneark-dumpfil … $
Vi vil nevne en siste måte å bruke depotdumpformatet i Subversion på – konvertering fra en annen lagringsmekanisme eller et annen versjonskontrollsystem. Fordi dumpfilformatet for det meste er lesbart for mennesker,[32] skulle det være relativt enkelt å beskrive generelle sett med forandringer – der hver av dem blir behandlet som en ny revisjon – ved å bruke dette filformatet. Faktisk bruker programmet cvs2svn (se “Konvertere et depot fra CVS til Subversion”) dumpformatet for å representere innholdet i et CVS-depot så dette innholdet kan bli kopiert inn i et Subversiondepot.
Tross utallige forbedringer i teknologien siden den moderne datamaskinen ble født, gjør fortsatt en ting seg sterkt gjeldende – noen ganger går ting forferdelig galt. Strømbrudd, nettverksbrudd, ødelagte minnebrikker og krasjede harddisker er bare en forsmak på ondskapen som Skjebnen er troende til å øse over selv den mest samvittighetsfulle administrator. Vi lander derfor på et meget viktig tema – hvordan du tar sikkerhetskopier av depotdataene dine.
Det er generelt sett to backupmetoder som er tilgjengelig for administratorer av Subversiondepot – inkrementell og fullstendig. Vi diskuterte i en tidligere seksjon i dette kapittelet hvordan svnadmin dump --incremental kan brukes til å utføre en inkrementell backup (se “Flytte et depot”). Essensen i idéen er at på det punktet kopien lages blir kun forandringene i depotet siden forrige backup tatt med.
En fullstendig kopi av depotet er bokstavelig talt en duplisering av hele depotkatalogen (som inkluderer enten en Berkeley-database eller et FSFS-miljø). Hvis du nå tar en kopi uten å midlertidig sperre all tilgang til depotet, vil det å bare ta en rekursiv katalogkopi kanskje føre til at det blir feil i kopien, siden noen kan skrive til databasen på samme tidspunkt.
I tilfellet med Berkeley DB beskriver dokumenter laget av
Sleepycat en viss rekkefølge databasefiler kan kopieres i som
vil garantere en gyldig sikkerhetskopi.
Og en lignende rekkefølge eksisterer for FSFS-data.
Enda bedre, du trenger ikke selv å implementere disse
algoritmene fordi det er allerede gjort av Subversionutviklerne.
Skriptet hot-backup.py ligger i
tools/backup/-katalogen i den distribuerte
Subversionkildekoden.
Ved å gi en depotsti og en backupplassering til
hot-backup.py – som egentlig bare er en mer
intelligent innpakning rundt svnadmin
hotcopy-kommandoen – vil den utføre de nødvendige
stegene for å ta backup av det aktive depotet ditt – uten at du
må sperre den offentlige tilgangen – og vil deretter rense bort
de døde Berkeleyloggfilene fra det aktive depotet.
Selv om du også har en inkrementell backup, vil du
sannsynligvis ville kjøre dette programmet med jevne mellomrom.
For eksempel vil du kanskje vurdere å legge til
hot-backup.py til en automatisk
programkjøring (som cron på Unix-systemer).
Eller, hvis du foretrekker finjusterte backupløsninger, kan du
sette post-commit-skriptet til å kalle
hot-backup.py (se “Påhakningsskript”), som vil lage en ny
kopi av depotet for hver ny revisjon som er opprettet.
Bare legg det følgende inn i
hook/post-commit-skriptet i katalogen til
det aktive depotet:
(cd /sti/til/påhakningsskript; \
./hot-backup.py ${REPOS} /sti/til/sikkerhetskopier &)
Den resulterende backupen er et fullstendig fungerende Subversiondepot som du kan legge inn som en erstatning for det aktive depotet i tilfelle noe skulle gå forferdelig galt.
Det er fordeler med begge backupmetodene. Den letteste er helt klart å ta en full sikkerhetskopi, som alltid vil resultere i en fullstendig funksjonell duplikat av depotet ditt. Dette betyr igjen at hvis noe stygt skulle skje med det aktive depotet, kan du hente det tilbake fra sikkerhetskopien med en enkel rekursiv katalogkopiering. Uheldigvis, hvis du har flere kopier av depotet, vil disse fullstendige kopiene spise opp like mye diskplass som det aktive depotet.
Inkrementelle backuper som bruker depotdumpformatet er utmerket å ha for hånden hvis oppbygningen av databasen forandrer seg mellom versjonene av selve Subversion. Siden en komplett depotdump og depotlasting vanligvis er nødvendig for å oppgradere depotet ditt til det nye formatet, er det veldig enkelt å allerede ha halvparten av denne prosessen (dumpdelen) overstått. Uheldigvis tar opprettelsen av – og gjenoppretting fra – inkrementelle backuper lengre tid, fordi hver innlegging enten blir spilt av inn i dumpfila eller depotet.
I begge disse backupscenariene må depotadminstratorer være oppmerksom på hvordan forandringer i uversjonerte revisjonsegenskaper påvirker sikkerhetskopiene. Siden disse forandringene ikke selv lager nye revisjoner, vil de ikke aktivisere post-commit-påhakninger, og kanskje heller ikke aktivisere pre-revprop-change- og post-revprop-change-skriptene.[33] Og siden du kan forandre revisjonsegenskaper som går på tvers av den kronolgiske rekkefølgen – du kan forandre enhver egenskap for en revisjon når som helst – vil en inkrementell backup av de seneste få revisjonene kanskje ikke fange opp en egenskapsforandring i en revisjon som ble inkludert som del av en tidligere backup.
Vanligvis vil bare den helt paranoide trenge å ta backup av hele depotet, la oss si, hver gang en innlegging skjer. Imidlertid, hvis vi antar at et gitt depot har noen ganske finjusterte mekanismer på plass (som utsending av epost for hver innlegging), vil en varm backup av databasen være noe som en depotadministrator vil ønske å inkludere som del av en nattlig systembackup. For de fleste depot vil arkiverte eposter alene gi nok informasjon som gjenopprettelseskilde, i hvert fall for de siste få innleggingene. Men det er dine data – beskytt dem i den grad du vil.
Ofte er den beste tilnærmingsmåten til kopier av depotet delt. Du kan sette opp kombinasjoner av fullstendige og inkrementelle backuper, pluss et arkiv med innleggingsmeldinger. Subversionutviklerne tar for eksempel backup av kildekodedepotet etter hver ny revisjon som opprettes, og tar vare på et arkiv med alle eposter som varsler om innlegginger og forandringer i revisjoner og egenskaper. Løsningen din kan være noe lignende, men bør tilpasses dine behov og følge den fine linjen mellom bekvemmelighet og paranoia. Og selv om dette ikke vil redde hardwaren din fra Skjebnens jernhånd, vil det helt sikkert hjelpe deg å komme deg på fote igjen etter harde tider som dette.
[29] Og det er forøvrig en funksjonalitet og ikke en feil.
[30] Selv om svnadmin dump har en konsekvent regel om innledende skråstreker – å ikke inkludere dem – kan det være at andre programmer som genererer dumpdata ikke er like konsekvente.
[31] Som for eksempel: Harddisk + kjempemagnet = krise.
[32] Dumpformatet i Subversion ligner et RFC-882-format, den samme typen format som vanligvis brukes i eposter.
[33] svnadmin setlog kan bli kjørt på en måte som går helt utenom påhakningsgrensesnittet.