Versjonskontroll med Subversion

Alle versjonskontrollsystemer må løse det samme fundamentale problemet: Hvordan vil systemet tillate brukere å dele informasjon, men forhindre dem fra å tråkke hverandre på tærne? Det er alt for lett for brukere å overskrive hverandres forandringer i depotet ved en ulykke.

Tenk over scenariet vist i Figur 2.2, “Problemet som må unngås”. Sett at vi har to arbeidskolleger, Harry og Sally. De bestemmer seg begge for å redigere den samme filen i depotet samtidig. Hvis Harry lagrer sine forandringer til depotet først, er det (noen øyeblikk senere) mulig at Sally feilaktig overskriver dem med hennes egen nye versjon av filen. Selv om Harrys versjon av filen ikke vil være tapt for alltid (fordi systemet husker hver eneste forandring), vil alle forandringene Harry gjorde ikke være med i Sallys nyere versjon av filen, fordi hun så aldri Harrys forandringer til å begynne med. Harrys arbeid er fortsatt borte – eller i det minste borte fra den siste versjonen av filen – og sannsynligvis ved en ulykke. Dette er definitivt en situasjon vi vil unngå!

Figur 2.2. Problemet som må unngås

Mange versjonskontrollsystemer bruker en modell av typen lås-rediger-lås opp når de tar for seg dette problemet. I et sånt system tillater depotet bare en person å forandre en fil om gangen. Først må Harry “låse” filen før han kan begynne med å gjøre forandringer i den. Låsing av en fil er mye likt det å låne en bok på biblioteket; hvis Harry har låst en fil kan ikke Sally gjøre forandringer i den. Hvis hun prøver å låse filen, vil ikke depotet tillate dette. Alt hun kan gjøre er å lese filen, og vente på at Harry gjør seg ferdig med sine forandringer og så slipper låsen han har satt opp. Etter at Harry låser opp filen, er hans tur over, og nå kan Sally ta sin runde med låsing og redigering. Figur 2.3, “Lås-rediger-lås opp-løsningen” demonstrerer denne enkle løsningen.

Figur 2.3. “Lås-rediger-lås opp”-løsningen

Problemet med “lås-rediger-lås opp”-metoden er at den er ganske restriktiv, og blir ofte en hindring for brukerne:

Subversion, CVS og andre versjonskontrollsystemer bruker en modell av typen kopier-rediger-flett som et alternativ til låsing. I denne modellen kontakter klienten til hver bruker prosjektdepotet og lager en personlig arbeidskopi – et lokalt speil av depotets filer og kataloger. Brukere arbeider så parallelt ved å modifisere deres private kopier. Til slutt blir de private kopiene flettet inn i en ny, endelig versjon. Versjonskontrollsystemet hjelper ofte til med flettingen, men til syvende og sist er det et menneske som er ansvarlig for å la det skje skikkelig.

Her er et eksempel. La oss si at Harry og Sally hver for seg lager arbeidskopier av det samme prosjektet, kopiert fra depotet. De arbeider samtidig, og gjør forandringer i den samme filen A innenfor sine kopier. Sally lagrer sine forandringer til depotet først. Når Harry prøver å lagre sine forandringer senere, informerer depotet ham om at hans fil A er utdatert. Med andre ord, filen A i depotet har på en eller annen måte forandret seg siden han kopierte den sist. Så Harry ber klienten sin om å flette alle nye forandringer fra depotet inn i hans arbeidskopi av fil A. Sjansene for at Sallys forandringer ikke overlapper med hans egne er store; så når begges forandringer er lagt inn i filen, lagrer han sin egen arbeidskopi til depotet. Figur 2.4, “Kopier-rediger-flett-løsningen” og Figur 2.5, “Kopier-rediger-flett-løsningen (forts.)” viser denne prosessen.

Figur 2.4. “Kopier-rediger-flett”-løsningen

Figur 2.5. “Kopier-rediger-flett”-løsningen (forts.)

Men hva hvis Sallys forandringer likevel overlapper med Harrys forandringer? Hva da? Denne situasjonen kalles en konflikt, og er vanligvis ikke mye til problem. Når Harry ber klienten sin om å flette sammen de nyeste forandringene i depotet inn i hans arbeidskopi, blir det vist at hans kopi av fil A er i konflikt: Han vil være i stand til å se begge settene av konfliktskapende forandringer, og velge mellom dem manuelt. Legg merke til at programvare ikke kan løse konflikter automatisk; bare mennesker er i stand til å forstå og gjøre de nødvendige intelligente valgene. Når Harry har løst de overlappende forandringene manuelt – kanskje etter en diskusjon med Sally – kan han trygt lagre den flettede filen tilbake til depotet.

“Kopier-rediger-flett”-modellen kan høres litt kaotisk ut, men i praksis går det ekstremt glatt. Brukere kan jobbe parallelt, og aldri vente på hverandre. Når de arbeider på de samme filene, viser det seg at mesteparten av de samtidige forandringene ikke overlapper i det hele tatt; konflikter er sjeldne. Og tiden det tar å løse konflikter er langt mindre enn tiden tapt med et låsesystem.

Til sist koker det hele ned til en kritisk faktor: Brukerkommunikasjon. Når brukerne kommuniserer dårlig, øker antallet av både programmessige og språkmessige konflikter. Ingen systemer kan tvinge brukerne til å kommunisere perfekt, og ingen systemer kan oppdage språkmessige konflikter. Så, det er ikke mye poeng i å bli lurt av et falskt løfte om at et låsesystem på en eller annen måte vil forhindre konflikter; i praksis ser låsing ut til å hemme produktiviteten mer enn noe annet.

Du har allerede lest om arbeidskopier; nå skal vi demonstrere hvordan Subversionklienten lager og bruker dem.

En arbeidskopi i Subversion er et vanlig katalogtre på ditt lokale system, og inneholder en samling filer. Du kan redigere disse filene sånn som du vil, og hvis det er kildekode, kan du kompilere programmet på den vanlige måten. Arbeidskopien din er ditt eget private arbeidsområde: Subversion vil aldri legge inn andre folks forandringer, heller ikke gjøre dine egne forandringer tilgjengelig for andre før du eksplisitt ber programmet om å gjøre det.

Etter at du har gjort noen forandringer i filene i arbeidskopien og sjekket at de virker skikkelig, gir Subversion deg kommandoer så du kan “publisere” forandringene dine til de andre som arbeider med deg på prosjektet ditt (ved å skrive til depotet). Hvis andre personer publiserer deres egne forandringer, gir Subversion deg kommandoer for å flette disse forandringene inn i din arbeidskopi (ved å lese fra depotet).

En arbeidskopi inneholder også noen ekstra filer, opprettet og vedlikeholdt av Subversion, for å hjelpe seg med å utføre disse kommandoene. Hver katalog i arbeidskopien inneholder en underkatalog kalt .svn, også kjent som arbeidskopiens administrative katalog. Filene i hver administrative katalog hjelper Subversion til å se hvilke filer som inneholder upubliserte forandringer, og hvilke filer som er utdaterte i forhold til andres arbeid.

Et typisk Subversiondepot inneholder ofte filene (eller kildekoden) for flere prosjekter; vanligvis har hvert prosjekt sin egen underkatalog i depotets filsystemtre. Med dette arrangementet vil en brukers arbeidskopi samsvare med et spesielt deltre av depotet.

For eksempel, tenk deg at du har et depot som består av to programprosjekter, paint og calc. Hvert prosjekt bor i hver sin toppkatalog, som vist i Figur 2.6, “Depotets filsystem”.

Figur 2.6. Depotets filsystem

For å få deg en arbeidskopi, må du først hente ut (check out) et del av et katalogtre fra depotet. (Det engelske uttrykket “check out” kan høres ut som det har noe å gjøre med låsing eller reservering av ressurser, men det har ikke det; det lager bare en privat kopi av prosjektet for deg.) For eksempel, hvis du henter ut /calc, vil du få en arbeidskopi som dette:

$ svn checkout http://svn.example.com/repos/calc
A  calc
A  calc/Makefile
A  calc/integer.c
A  calc/button.c

$ ls -A calc
Makefile  integer.c  button.c  .svn/

Listen med bokstaven A indikerer at Subversion legger til et antall elementer i arbeidskopien din. Du har nå en personlig kopi av depotets /calc-katalog, med en ekstra komponent – .svn – som tidligere nevnt inneholder den ekstra informasjonen som Subversion trenger.

$ svn checkout file:///sti/til/depot
…
$ svn checkout file://localhost/sti/til/depot
…

C:\> svn checkout file:///X:/path/to/repos
…
C:\> svn checkout "file:///X|/path/to/repos"
…

Tenk at du gjør forandringer til button.c. Siden .svn-katalogen husker filens modifiseringsdato og originale innhold, kan Subversion se at du har forandret filen. Men Subversion offentliggjør ikke dine forandringer før du eksplisitt ber programmet om å gjøre det. Prosessen når du publiserer dine forandringer blir vanligvis omtalt som å legge inn (eller sende/sjekke inn) forandringer til depotet.

For å publisere dine forandringer til andre, kan du bruke Subversions commit-kommando:

$ svn commit button.c
Sending        button.c
Transmitting file data .
Committed revision 57.

Nå er dine forandringer til button.c lagt inn i depotet; hvis en annen bruker henter ut en arbeidskopi av /calc, vil de se dine forandringer i den seneste versjonen av filen.

Tenk deg at du har en samarbeidspartner, Sally, som hentet ut en arbeidskopi av /calc samtidig med deg. Når du legger inn din forandring til button.c, er Sallys arbeidskopi uforandret; Subversion modifiserer bare arbeidskopier etter brukerens ønske.

For å få sitt prosjekt oppdatert, kan Sally be Subversion om å oppdatere hennes arbeidskopi, ved å bruke Subversionkommandoen update. Dette vil legge inn dine forandringer inn i hennes arbeidskopi, så vel som alle andre forandringer som er blitt lagt inn i depotet siden hun sist hentet det ut.

$ pwd
/home/sally/calc

$ ls -A 
.svn/ Makefile integer.c button.c

$ svn update
U button.c

Utdataene fra kommandoen svn update indikerer at Subversion oppdaterte innholdet av button.c. Legg merke til at Sally ikke trengte å spesifisere hvilke filer som skulle oppdateres, Subversion bruker informasjonen i .svn-katalogen sammen med annen informasjon i depotet for å bestemme hvilke filer som trenger en oppdatering.

En svn commit-operasjon kan publisere forandringer til ethvert antall filer og kataloger som en enkeltstående atomisk transaksjon. I arbeidskopien din kan du forandre filenes innhold, opprette, slette, skifte navn og kopiere filer og kataloger, og så legge inn det komplette settet med forandringer som en samlet enhet.

I depotet blir hver innlegging behandlet som en atomisk transaksjon: Enten blir alle forandringene lagt inn, eller så blir ingen lagt inn. Subversion prøver å beholde denne atomiteten stilt opp mot programkræsj, systemkræsj, nettverksproblemer og andre brukeres aktiviteter.

Hver gang depotet aksepterer en innlegging, opprettes det en ny tilstand i filsystemtreet, kalt en revisjon. Hver revisjon blir tildelt et unikt naturlig tall, ett større enn nummeret på den forrige revisjonen. Den første revisjonen i et nyopprettet depot har nummeret null, og inneholder ingenting annet enn en tom rotkatalog.

Figur 2.7, “Depotet” illustrerer en fin måte å visualisere depotet på. Tenk deg en rekke av revisjonsnumre som starter på 0 og strekker seg fra venstre mot høyre. Hvert revisjonsnummer har et filsystemtre hengende under seg, og hvert tre er et “øyeblikksbilde” av hvordan depotet så ut etter en innlegging.

Figur 2.7. Depotet

Det er viktig å notere seg at arbeidskopier ikke bestandig samsvarer med en enkelt revisjon i depotet; de kan inneholde filer fra flere forskjellige revisjoner. For eksempel, tenk at du henter ut en arbeidskopi fra et depot der den siste revisjonen er 4:

calc/Makefile:4
     integer.c:4
     button.c:4

For øyeblikket samsvarer arbeidskopien nøyaktig med revisjon 4 i depotet. Men tenk deg så at du gjør en forandring i button.c, og legger inn denne forandringen. Forutsatt at ingen andre innlegginger har forekommet, vil din innlegging opprette revisjon 5 i depotet, og arbeidskopien din vil se ut som dette:

calc/Makefile:4
     integer.c:4
     button.c:5

Så sier vi at Sally på dette tidspunktet legger inn en forandring til integer.c, som lager revisjon 6. Hvis du bruker svn update for å oppdatere arbeidskopien, vil den se ut som dette:

calc/Makefile:6
     integer.c:6
     button.c:6

Sallys forandring i integer.c vil komme til syne i arbeidskopien din, og din forandring vil fortsatt være til stede i button.c. I dette eksempelet er teksten i Makefile identisk i revisjon 4, 5 og 6, men Subversion vil merke kopien av Makefile med revisjon 6 for å indikere at den fortsatt gjelder. Så, etter at du gjør en ren oppdatering fra toppen av arbeidskopien din, vil den vanligvis samsvare med en eksakt revisjon i depotet.

For hver fil i en arbeidskatalog, lagrer Subversion to essensielle deler informasjon i det administrative .svn-området:

Ved hjelp av denne informasjonen kan Subversion ved å kommunisere med depotet se hvilke fire tilstander en arbeidsfil er i:

Dette kan høres ut som mye å holde greie på, men svn status-kommandoen vil vise deg tilstanden til ethvert element i arbeidskopien din. For mer informasjon om denne kommandoen, se “svn status”.

Som et generelt prinsipp prøver Subversion å være så fleksibel som mulig. En spesiell type av fleksibilitet er muligheten til å ha en arbeidskopi som inneholder blandede revisjonsnumre.

Til å begynne med er det ikke sikkert det er helt klart hvorfor denne typen fleksibilitet er å betrakte som en fordel, og ikke en svakhet. Etter å ha fullført en innlegging i depotet, er de nylig innlagte filene og katalogene i en nyere arbeidsrevisjon enn resten av kopien. Det ser ut som litt av et rot. Som tidligere demonstrert, kan arbeidskopien alltid bli satt til en enkelt arbeidsrevisjon ved å kjøre svn update. Hvorfor vil noen med vilje ønske seg en blanding av arbeidsrevisjoner?

Forutsatt at prosjektet ditt er komplekst nok, vil du oppdage at det noen ganger er fint å kunne “tilbakedatere” deler av arbeidskopien til en tidligere revisjon; du vil lære hvordan du gjør dette i kapittel 3. Kanskje vil du prøve en tidligere versjon av en delmodul, lagret i en underkatalog, eller kanskje du vil utforske et antall tidligere versjoner av en fil sett i forhold til det seneste treet.

Hvordan du enn gjør bruk av blandede revisjoner i arbeidskopien, er det begrensninger i denne fleksibiliteten.

For det første kan du ikke legge inn sletting av en fil eller katalog som ikke er fullstendig oppdatert. Hvis en nyere versjon av elementet eksisterer i depotet, vil forsøket ditt på å slette bli avslått, for å forhindre deg å feilaktig ødelegge forandringer som du enda ikke har sett.

For det andre kan du ikke legge inn en metadata-forandring til en katalog hvis den ikke er fullstendig oppdatert. Du vil få lære om å legge til “egenskaper” til elementer i kapittel 6. En katalogs arbeidsrevisjon definerer et spesifikt sett med poster og egenskaper, og en innlegging av forandringer i en egenskap for en utdatert katalog kan ødelegge egenskaper som du enda ikke har sett.

Når du lager et nytt Subversiondepot, begynner det livet sitt på revisjon null og hver etterfølgende innlegging øker revisjonsnummeret med en. Etter at innleggingen din er fullført, informerer Subversionklienten deg om det nye revisjonsnummeret:

$ svn commit --message "Corrected number of cheese slices."
Sending        sandwich.txt
Transmitting file data .
Committed revision 3.

Hvis du på et punkt i fremtiden vil referere til den revisjonen (vi vil se hvordan og hvorfor vi kanskje skulle ønske å gjøre det senere i dette kapitlet), kan du referere til den som “3”.

Subversionklienten forstår noen revisjonsnøkkelord. Disse nøkkelordene kan bli brukt istedenfor heltallsargumenter til --revision-valget, og blir oversatt til spesifikke revisjonsnumre av Subversion:

Her er noen eksempler på revisjonsnøkkelord i aksjon. Ikke bli urolig om du ikke forstår den fulle betydningen av kommandoene enda; vi vil forklare disse kommandoene mens vi går gjennom kapittelet:

$ svn diff --revision PREV:COMMITTED foo.c
# viser den siste forandringen lagt inn til foo.c

$ svn log --revision HEAD
# viser loggmelding for den seneste innleggingen i depotet

$ svn diff --revision HEAD
# sammenligner arbeidsfilen din (med lokale forandringer) med den 
# seneste versjonen i depotet.

$ svn diff --revision BASE:HEAD foo.c
# sammenligner din “uberørte” foo.c (ingen lokale 
# modifikasjoner) mot den seneste versjonen i depotet.

$ svn log --revision BASE:HEAD
# viser alle loggmeldinger siden du sist oppdaterte

$ svn update --revision PREV foo.c
# setter tilbake til den forrige forandringen på foo.c .
# (Arbeidsrevisjonen til foo.c minsker.)

Disse nøkkelordene tillater deg å utføre mange vanlige (og hjelpsomme) operasjoner uten å måtte lete opp spesielle revisjonsnumre eller huske den eksakte revisjonen til arbeidskopien din.

Alle plasser du spesifiserer et revisjonsnummer eller revisjonsnøkkelord, kan du også spesifisere en dato innenfor krøllparenteser “{}”. Du kan til og med aksessere et område av forandringer i depotet ved å bruke både datoer og revisjoner sammen!

Her er eksempler på dataformater som Subversion aksepterer. Husk å bruke anførselstegn rundt datoer som inneholder mellomrom.

$ svn checkout --revision {2002-02-17}
$ svn checkout --revision {15:30}
$ svn checkout --revision {15:30:00.200000}
$ svn checkout --revision {"2002-02-17 15:30"}
$ svn checkout --revision {"2002-02-17 15:30 +0230"}
$ svn checkout --revision {2002-02-17T15:30}
$ svn checkout --revision {2002-02-17T15:30Z}
$ svn checkout --revision {2002-02-17T15:30-04:00}
$ svn checkout --revision {20020217T1530}
$ svn checkout --revision {20020217T1530Z}
$ svn checkout --revision {20020217T1530-0500}
…

Når du spesifiserer en dato som en revisjon, finner Subversion den nyeste revisjonen på denne datoen:

$ svn log --revision {2002-11-28}
------------------------------------------------------------------------
r12 | ira | 2002-11-27 12:31:51 -0600 (Wed, 27 Nov 2002) | 6 lines
…

Du kan også bruke et område av datoer. Subversion vil finne alle revisjoner mellom to datoer, inkludert:

$ svn log --revision {2002-11-20}:{2002-11-29}
…

Som vi har påpekt, kan du også blande datoer og revisjoner:

$ svn log --revision {2002-11-20}:4040

Brukere bør være klar over en spissfindighet som kan bli litt av en snublestein ved bruk av datoer i Subversion. Siden tidspunktet på en revisjon er lagret som en egenskap for revisjonen – en uversjonert, modifiserbar egenskap – kan revisjonsegenskaper bli forandret til å representere helt feil kronologi, eller kan til og med bli fjernet helt. Dette vil rote til den interne “dato-til-revisjon”-konverteringen som Subversion utfører.

Når du arbeider på et prosjekt med et team, vil du oppdatere arbeidskopien din med alle forandringer gjort av andre utviklere siden den forrige oppdateringen av prosjektet. Bruk svn update for å få arbeidskopien i synk med den siste revisjonen i depotet.

$ svn update
U  foo.c
U  bar.c
Updated to revision 2.

I dette tilfellet har noen andre lagt inn forandringer til både foo.c og bar.c siden forrige gang du oppdaterte, og Subversion har oppdatert arbeidskopien din til å inneholde disse forandringene.

La oss se på utdataene fra svn update litt til. Når tjeneren sender forandringer til arbeidskopien, blir en bokstavkode vist ved siden av hvert element for å la deg vite hva Subversion gjorde for å oppdatere arbeidskopien:

Nå kan du gå i gang med arbeidet og gjøre forandringer i arbeidskopien. Det er vanligvis mer praktisk å bestemme seg for en spesiell forandring (eller et sett forandringer) som skal gjøres, som å lage en ny funksjonalitet, ordne en feil osv. Subversionkommandoene som du vil bruke her er svn add, svn delete, svn copy og svn move. Hvis du imidlertid bare redigerer filer som allerede finnes i Subversion, trenger du kanskje ikke å bruke noen av disse kommandoene før du legger dem inn. Forandringer som du kan gjøre med arbeidskopien:

For å gjøre forandringer i filer, bruk teksteditoren din, tekstbehandlingsprogrammet, grafikkprogrammet, eller hvilket som helst verktøy du vanligvis bruker. Subversion behandler binærfiler like lett som tekstfiler – og like effektivt.

Her er en oversikt over de fire delkommandoene i Subversion som du vil bruke oftest for å gjøre forandringer i trestrukturen (vi vil dekke svn import og svn mkdir senere).

Når du er ferdig med å gjøre forandringer, må du legge dem inn i depotet, men før du gjør det, er det vanligvis en god idé å ta en kikk på nøyaktig hva du har forandret. Ved å studere forandringene dine før du legger dem inn, kan du lage en mer nøyaktig loggmelding. Du kan også oppdage om du har forandret en fil ved en ulykke, og dette gir deg en sjanse til å omgjøre disse forandringene før du legger dem inn. I tillegg er dette en god mulighet til å se over og skrote forandringer før du publiserer dem. Du kan se nøyaktig hvilke forandringer du har gjort ved å bruke svn status, svn diff og svn revert. Du vil vanligvis bruke de første to kommandoene til å finne ut hvilke filer som har forandret seg i arbeidskopien din, og deretter kanskje bruke den tredje for å omgjøre noen (eller alle) disse forandringene.

Subversion er blitt optimalisert for å hjelpe deg med denne oppgaven, og er i stand til å gjøre mange ting uten å kommunisere med depotet. Nærmere forklart, arbeidskopien inneholder en hemmelig “urørt” kopi av hver versjonskontrollert fil, og disse kopiene ligger i .svn-området. På grunn av dette kan Subversion raskt vise deg hvordan arbeidsfilene dine har forandret seg, og til og med tillate deg å omgjøre forandringene dine uten å kontakte depotet.

  L    abc.c               # svn har en lås i .svn-katalogen for abc.c
M      bar.c               # innholdet i bar.c har lokale forandringer
 M     baz.c               # baz.c har egenskapsforandringer, men ingen 
                           # forandring i innholdet
X      3rd_party           # denne katalogen er del av en 
                           # 'externals'-definering
?      foo.o               # svn kjenner ikke til foo.o
!      some_dir            # svn kontrollerer ikke denne, og er satt opp 
                           # til å ignorere den
~      qux                 # versjonert som fil/katalog/lenke, men 
                           # elementtypen er forandret
I      .screenrc           # denne filen er ignorert
A  +   moved_dir           # lagt til med historien til der den kom fra
M  +   moved_dir/README    # lagt til med historie og inneholder lokale 
                           # forandringer
D      stuff/fish.c        # denne filen er klargjort for sletting
A      stuff/loot/bloo.h   # denne filen er klargjort for tillegging
C      stuff/loot/lump.c   # denne filen inneholder en konflikt fra en 
R      xyz.c               # denne filen er klargjort for erstatning
                           # oppdatering
    S  stuff/squawk        # denne filen eller katalogen er byttet til 
                           # en annen plassering i depotet ved hjelp av 
                           # svn switch-kommandoen 

$ svn status stuff/fish.c
D      stuff/fish.c

$ svn status --verbose
M               44        23    sally     README
                44        30    sally     INSTALL
M               44        20    harry     bar.c
                44        18    ira       stuff
                44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
                44        21    sally     stuff/things
A                0         ?     ?        stuff/things/bloo.h
                44        36    harry     stuff/things/gloo.c

$ svn status --show-updates --verbose
M      *        44        23    sally     README
M               44        20    harry     bar.c
       *        44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
A                0         ?     ?        stuff/things/bloo.h
Status against revision:   46

$ svn diff
Index: bar.c
===================================================================
--- bar.c	(revision 3)
+++ bar.c	(working copy)
@@ -1,7 +1,12 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+
+#include <stdio.h>

 int main(void) {
-  printf("Sixty-four slices of American Cheese...\n");
+  printf("Sixty-five slices of American Cheese...\n");
 return 0;
 }

Index: README
===================================================================
--- README	(revision 3)
+++ README	(working copy)
@@ -193,3 +193,4 @@ 
+Note to self:  pick up laundry.

Index: stuff/fish.c
===================================================================
--- stuff/fish.c	(revision 1)
+++ stuff/fish.c	(working copy)
-Welcome to the file known as 'fish'.
-Information on fish will be here soon.

Index: stuff/things/bloo.h
===================================================================
--- stuff/things/bloo.h	(revision 8)
+++ stuff/things/bloo.h	(working copy)
+Here is a new file to describe
+things about bloo.

$ svn diff > patchfil

$ svn revert README
Reverted 'README'

$ svn status foo
?      foo

$ svn add foo
A         foo

$ svn revert foo
Reverted 'foo'

$ svn status foo
?      foo

$ svn status README 
       README

$ svn delete README 
D         README

$ svn revert README
Reverted 'README'

$ svn status README
       README

Vi har allerede sett hvordan svn status -u kan forutsi konflikter. Tenk deg at du kjører svn update og noen interessante ting skjer:

$ svn update
U  INSTALL
G  README
C  bar.c
Updated to revision 46.

Kodene U og G gir ingen grunn til å foreta seg noe; disse filene absorberte forandringene fra depotet på en grei måte. Filene merket med U inneholdt ingen lokale forandringer, men ble oppdatert (Updated) med forandringer fra depotet. G-en står for “merGed” (flettet), noe som betyr at filen hadde lokale forandringer til å begynne med, men forandringene som kom fra depotet overlappet ikke med de lokale forandringene.

Men C-en står for konflikt. Dette betyr at forandringene fra tjeneren overlappet med dine egne, og nå må du velge mellom dem manuelt.

Når en konflikt oppstår, skjer vanligvis tre ting som hjelper deg med å legge merke til og løse denne konflikten:

For eksempel, Sally gjør forandringer til filen sandwich.txt i depotet. Harry har akkurat forandret filen i arbeidskopien sin og har lagt den inn. Sally oppdaterer sin arbeidskopi før hun legger den inn og får en konflikt:

$ svn update
C  sandwich.txt
Updated to revision 2.
$ ls -1
sandwich.txt
sandwich.txt.mine
sandwich.txt.r1
sandwich.txt.r2

På dette tidspunktet vil Subversion ikke tillate deg å legge inn filen sandwich.txt før de tre midlertidige filene er fjernet.

$ svn commit --message "Add a few more things"
svn: Commit failed (details follow):
svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict

Hvis du får en konflikt, må du gjøre en av tre ting:

Når du har løst konflikten, må du la Subversion få vite dette ved å kjøre svn resolved. Dette fjerner de tre midlertidige filene og Subversion anser ikke lenger filen for å være i konflikt.^[4]

$ svn resolved sandwich.txt
Resolved conflicted state of 'sandwich.txt'

$ cat sandwich.txt
Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
Creole Mustard
Bottom piece of bread

<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======

=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2

Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
Creole Mustard
Bottom piece of bread

$ svn resolved sandwich.txt
$ svn commit -m "Go ahead and use my sandwich, discarding Sally's edits."

$ svn update
C  sandwich.txt
Updated to revision 2.
$ ls sandwich.*
sandwich.txt  sandwich.txt.mine  sandwich.txt.r2  sandwich.txt.r1
$ cp sandwich.txt.r2 sandwich.txt
$ svn resolved sandwich.txt

$ svn revert sandwich.txt
Reverted 'sandwich.txt'
$ ls sandwich.*
sandwich.txt

Nå er du klar til å legge inn forandringene dine. Legg merke til at svn resolved, ulikt mesteparten av de andre kommandoene vi har holdt på med i dette kapittelet, trenger et argument. I alle tilfeller må du være forsiktig og bare kjøre svn resolved når du er sikker på at du har ordnet konflikten i filen – når de midlertidige filene er fjernet, vil Subversion la deg legge inn filen selv om den fortsatt inneholder konfliktmerker.

Endelig! Du er ferdig med forandringene dine, du har flettet inn alle forandringene fra tjeneren, og du er klar til å legge inn forandringene til depotet.

Kommandoen svn commit sender alle dine forandringer til depotet. Når du legger inn en forandring, må du skrive en loggmelding som beskriver forandringen. Loggmeldingen vil bli lagt ved den nye revisjonen som du lager. Hvis loggmeldingen er kort, vil du kanskje legge den inn fra kommandonlinjen ved å bruke --message (eller -m)-valget:

$ svn commit --message "Corrected number of cheese slices."
Sending        sandwich.txt
Transmitting file data .
Committed revision 3.

Hvis du derimot har laget loggmeldingen mens du arbeidet, vil du kanskje be Subversion om å hente meldingen fra en fil ved å angi filnavnet med --file-valget:

$ svn commit --file logmsg 
Sending        sandwich.txt
Transmitting file data .
Committed revision 4.

Hvis du lar være å angi --message- eller --file-valget, vil Subversion starte favoritteditoren din automatisk (se seksjonen om editor-cmd i “Config”) så du kan skrive en loggmelding.

$ svn commit
Waiting for Emacs...Done

Log message unchanged or not specified
a)bort, c)ontinue, e)dit
a
$

Depotet vet ikke og bryr seg ikke om forandringene dine gir noen mening som helhet; det sjekker bare for å være sikker på at ingen andre har forandret noen av de samme filene som du gjorde når du ikke fulgte med. Hvis noen har gjort det, vil hele innleggingen feile med en melding om at en eller flere av filene dine er utdaterte:

$ svn commit --message "Add another rule"
Sending        rules.txt
svn: Commit failed (details follow):
svn: Out of date: 'rules.txt' in transaction 'g'

På dette punktet må du kjøre svn update, ta deg av eventuelle flettinger eller konflikter som oppstår og prøve en ny innlegging.

Dette dekker den grunnleggende arbeidssyklusen for å bruke Subversion. Det er mange andre funksjoner i Subversion som du kan bruke til å vedlikeholde depotet og arbeidskopien, men du kan klare deg ganske greit ved å bare bruke de kommandoene som vi har diskutert så langt i kapittelet.

For å finne informasjon om historien til en fil eller katalog, bruk kommandoen svn log. svn log vil gi deg en oversikt over hvem som gjorde forandringer i en fil eller katalog, i hvilken revisjon den forandret seg, tid og dato for denne revisjonen, og, hvis den ble skrevet, loggmeldingen som hører til innleggingen.

$ svn log
------------------------------------------------------------------------
r3 | sally | Mon, 15 Jul 2002 18:03:46 -0500 | 1 line

Added include lines and corrected # of cheese slices.
------------------------------------------------------------------------
r2 | harry | Mon, 15 Jul 2002 17:47:57 -0500 | 1 line

Added main() methods.
------------------------------------------------------------------------
r1 | sally | Mon, 15 Jul 2002 17:40:08 -0500 | 1 line

Initial import
------------------------------------------------------------------------

Legg merke til at loggmeldinger listes ut i omvendt kronologisk rekkefølge som standard. Hvis du ønsker å se et annet område av revisjoner i en spesiell rekkefølge, eller bare en enkelt revisjon, bruk --revision (-r)-valget:

$ svn log --revision 5:19    # viser loggene 5 til 19 i kronologisk 
                             # rekkefølge

$ svn log -r 19:5            # viser loggene 5 til 19 i omvendt 
                             # rekkefølge

$ svn log -r 8               # viser loggen for revisjon 8

Du kan også undersøke logghistorien for en enkelt fil eller katalog. For eksempel:

$ svn log foo.c
…
$ svn log http://foo.com/svn/trunk/code/foo.c
…

Dette vil vise loggmeldinger bare for de revisjonene der arbeidsfilen (eller URLen) forandret seg.

Hvis du vil ha enda mer informasjon om en fil eller katalog, tar svn log også et --verbose (-v)-valg. Fordi Subversion tillater deg å flytte og kopiere filer og kataloger, er det viktig å ha muligheten til å følge stiforandringer i filsystemet, så i “verbose”-modus vil svn log inkludere en liste over forandrede stier for en revision i listeformatet:

$ svn log -r 8 -v
------------------------------------------------------------------------
r8 | sally | 2002-07-14 08:15:29 -0500 | 1 line
Changed paths:
M /trunk/code/foo.c
M /trunk/code/bar.h
A /trunk/code/doc/README

Frozzled the sub-space winch.

------------------------------------------------------------------------

$ svn log -r 2
------------------------------------------------------------------------
$

Vi har allerede sett svn diff før – den viser filforskjeller i unified diff-format; den ble brukt til å vise de lokale forandringene i en arbeidskopi før de ble lagt inn i depotet.

Faktisk skal det vise seg at det er tre distinkte bruksmåter for svn diff:

$ svn diff
Index: rules.txt
===================================================================
--- rules.txt	(revision 3)
+++ rules.txt	(working copy)
@@ -1,4 +1,5 @@
 Be kind to others
 Freedom = Responsibility
 Everything in moderation
-Chew with your mouth open
+Chew with your mouth closed
+Listen when others are speaking
$

$ svn diff --revision 3 rules.txt 
Index: rules.txt
===================================================================
--- rules.txt	(revision 3)
+++ rules.txt	(working copy)
@@ -1,4 +1,5 @@
 Be kind to others
 Freedom = Responsibility
 Everything in moderation
-Chew with your mouth open
+Chew with your mouth closed
+Listen when others are speaking
$

$ svn diff --revision 2:3 rules.txt 
Index: rules.txt
===================================================================
--- rules.txt	(revision 2)
+++ rules.txt	(revision 3)
@@ -1,4 +1,4 @@
 Be kind to others
-Freedom = Chocolate Ice Cream
+Freedom = Responsibility
 Everything in moderation
 Chew with your mouth open
$

$ svn diff --revision 4:5 http://svn.red-bean.com/repos/example/trunk/text/rules.txt
…
$

Hvis du vil undersøke en tidligere versjon av en fil og ikke nødvendigvis forskjellene mellom to filer, kan du bruke svn cat:

$ svn cat --revision 2 rules.txt 
Be kind to others
Freedom = Chocolate Ice Cream
Everything in moderation
Chew with your mouth open
$

Du kan også omdirigere utdataene direkte til en fil:

$ svn cat --revision 2 rules.txt > rules.txt.v2
$

Du lurer sikkert på hvorfor vi rett og slett ikke bare bruker svn update --revision for å oppdatere filen til den eldre revisjonen. Det er et par grunner til at vi kanskje foretrekker å bruke svn cat.

For det første kan det hende at du ønsker å se på forskjellene mellom to revisjoner av en fil ved å bruke et eksternt diffprogram (kanskje et grafisk et, eller kanskje filen din er i et format som gjør at unified diff-formatet ikke strekker til). I dette tilfellet må du hente en kopi av den gamle revisjonen, omdirigere den til en fil, og angi både den og filen i arbeidskopien til det eksterne diffprogrammet.

Noen ganger er det lettere å se på en eldre versjon av en fil i sin helhet i stedet for bare forskjellene mellom den og en annen revisjon.

svn list-kommandoen viser deg hvilke filer som er i en depotkatalog uten å hente filene til din lokale maskin:

$ svn list http://svn.collab.net/repos/svn
README
branches/
clients/
tags/
trunk/

Hvis du vil ha en mer detaljert liste, angi --verbose (-v)-flagget for å få en liste som dette:

$ svn list --verbose http://svn.collab.net/repos/svn
   2755 harry          1331 Jul 28 02:07 README
   2773 sally               Jul 29 15:07 branches/
   2769 sally               Jul 29 12:07 clients/
   2698 harry               Jul 24 18:07 tags/
   2785 sally               Jul 29 19:07 trunk/

Kolonnene viser deg revisjonen filen eller katalogen sist ble modifisert, brukeren som gjorde det, størrelsen hvis det er en fil, datoen den sist ble forandret, og elementets navn.

I tillegg til alle de ovennevnte kommandoene, kan du bruke svn update og svn checkout med --revision-valget for å ta en hel arbeidskopi “tilbake i tid”^[6]:

$ svn checkout --revision 1729 # Henter ut en ny arbeidskopi fra r1729
…
$ svn update --revision 1729 # Oppdaterer en eksisterende arbeidskopi 
                             # til r1729
…

Når Subversion modifiserer arbeidskopien din (eller noe som helst i .svn), prøver programmet å gjøre det på en så trygg måte som mulig. Før arbeidskopien blir forandret, skriver Subversion det som skal utføres til en loggfil. Deretter kjører programmet kommandoene i loggfilen for å utføre forandringen det blir bedt om. Til slutt fjerner Subversion loggfilen. Arkitekturmessig er dette likt et journalfilsystem. Hvis en Subversionoperasjon blir avbrutt (hvis prosessen blir drept eller maskinen krasjer, for eksempel), blir loggfilen liggende på disken. Ved å utføre kommandoene i loggfilen en gang til kan Subversion fullføre den tidligere påbegynte operasjonen, og arbeidskopien din kan sette seg tilbake til en fullverdig tilstand.

Og dette er nøyaktig hva svn cleanup gjør: Den leter gjennom arbeidskopien og kjører alle etterlatte logger mens den fjerner låser under prosessen. Hvis Subversion noen ganger forteller deg at en del av arbeidskopien er “låst” (locked), er dette kommandoen du bør kjøre. I tillegg vil svn status vise en L ved siden av låste elementer:

$ svn status
  L    somedir
M      somedir/foo.c 

$ svn cleanup
$ svn status
M      somedir/foo.c

svn import-kommandoen er en rask måte å kopiere et uversjonert filtre inn i et depot og lage mellomliggende kataloger der det er nødvendig.

$ svnadmin create /usr/local/svn/nyttdepot
$ svn import mitt_tre file:///usr/local/svn/nyttdepot/etellerannet/prosjekt
Adding         mitt_tre/foo.c
Adding         mitt_tre/bar.c
Adding         mitt_tre/subdir
Adding         mitt_tre/subdir/quux.h

Committed revision 1.

Det forrige eksempelet kopierte innholdet av katalogen mitt_tre under katalogen etellerannet/prosjekt i depotet:

$ svn list file:///usr/local/svn/nyttdepot/etellerannet/prosjekt
bar.c
foo.c
subdir/

Legg merke til at etter importen er fullført, blir det originale treet ikke konvertert til en arbeidskopi. For å starte arbeidet, trenger du fortsatt å kjøre svn checkout for å få en fersk arbeidskopi av treet.

Det å opprette en ny gren er veldig enkelt – du lager en kopi av prosjektet i depotet ved å bruke kommandoen svn copy. Subversion er ikke bare i stand til å kopiere enkle filer, men også hele kataloger. I dette tilfellet vil du lage en kopi av /calc/trunk-katalogen. Hvor skal den nye kopien være? Hvor du vil – det er et spørsmål om prosjektrutiner. La oss si at teamet ditt har som regel å opprette forgreninger i /calc/branches-området i depotet, og du vil kalle grenen din my-calc-branch. Det du vil er å lage en ny katalog, /calc/branches/my-calc-branch, som begynner livet som en kopi av /calc/trunk.

Det er to forskjellige måter å lage en kopi på. Vi vil demonstrere den rotete måten først, bare for å klargjøre konseptet. Til å begynne med, hent ut en arbeidskopi av prosjektets rotkatalog, /calc:

$ svn checkout http://svn.example.com/repos/calc bigwc
A  bigwc/trunk/
A  bigwc/trunk/Makefile
A  bigwc/trunk/integer.c
A  bigwc/trunk/button.c
A  bigwc/branches/
Checked out revision 340.

For å lage en kopi er det nå bare å angi to arbeidskopistier til kommandoen svn copy:

$ cd bigwc
$ svn copy trunk branches/my-calc-branch
$ svn status
A  +   branches/my-calc-branch

I dette tilfellet kopierer svn copy katalogen trunk rekursivt til en ny arbeidskatalog, branches/my-calc-branch. Som du kan se av kommandoen svn status er den nye katalogen nå klargjort for å legges til i depotet. Men legg også merke til “+”-tegnet ved siden av bokstaven A. Dette indikerer at den klargjorte tilleggingen er en kopi av noe, og ikke noe nytt. Når du legger inn forandringene dine, vil Subversion lage /calc/branches/my-calc-branch i depotet ved å kopiere /calc/trunk istedenfor å sende hele arbeidskopien over nettverket en gang til:

$ svn commit -m "Creating a private branch of /calc/trunk."
Adding         branches/my-calc-branch
Committed revision 341.

Og nå den lettere måten å lage en gren på, som vi skulle fortalt deg om til å begynne med: svn copy kan operere direkte mot to URLer.

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/my-calc-branch \
      -m "Lager en privat gren av /calc/trunk."

Committed revision 341.

Det er egentlig ingen forskjell på disse to metodene. Begge prosedyrene lager en ny katalog i revisjon 341, og den nye katalogen er en kopi av /calc/trunk. Dette er vist i Figur 4.3, “Depot med ny kopi”. Legg merke til at den andre metoden utfører en øyeblikkelig innlegging.^[7] Det er en lettere prosedyre, fordi det ikke kreves at du må hente ut et stort speil av depotet. Faktisk trenger du med denne teknikken ikke en arbeidskopi i det hele tatt.

Figur 4.3. Depot med ny kopi

Nå som du har laget en gren av prosjektet, kan du hente ut en ny arbeidskopi for å starte bruken av den:

$ svn checkout http://svn.example.com/repos/calc/branches/my-calc-branch
A  my-calc-branch/Makefile
A  my-calc-branch/integer.c
A  my-calc-branch/button.c
Checked out revision 341.

Det er ingenting spesielt med denne arbeidskopien; den avspeiler simpelthen bare en annen katalog i depotet. Men når du legger inn forandringer, vil ikke Sally se noen av dem når hun oppdaterer. Hennes arbeidskopi er fra /calc/trunk. (Pass på å lese “Bytte om en arbeidskopi” senere i dette kapittelet: Kommandoen svn switch er en alternativ måte å lage en arbeidskopi av en forgrening.)

La oss late som om en uke går, og de følgende innlegginger blir gjort:

Det er nå to uavhengige utviklingslinjer, vist i Figur 4.4, “Forgreningen av en fils historie”, som skjer med integer.c.

Figur 4.4. Forgreningen av en fils historie

Ting blir interessante når du ser på historien til forandringene gjort i din kopi av integer.c:

$ pwd
/home/user/my-calc-branch

$ svn log --verbose integer.c
------------------------------------------------------------------------
r343 | user | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   M /calc/branches/my-calc-branch/integer.c

* integer.c:  frozzled the wazjub.

------------------------------------------------------------------------
r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   A /calc/branches/my-calc-branch (from /calc/trunk:340)

Creating a private branch of /calc/trunk.

------------------------------------------------------------------------
r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  changed a docstring.

------------------------------------------------------------------------
r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  adding this file to the project.

------------------------------------------------------------------------

Legg merke til at Subversion går gjennom historien av forgreningens integer.c hele veien tilbake gjennom tiden og krysser til og med punktet den ble kopiert. Opprettelsen av forgreningen vises som en hendelse i historien, fordi integer.c også ble kopiert når alt under /calc/trunk/ ble kopiert. Se nå hva som skjer når Sally kjører den samme kommandoen på hennes kopi av filen:

$ pwd
/home/sally/calc

$ svn log --verbose integer.c
------------------------------------------------------------------------
r344 | sally | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  fix a bunch of spelling errors.

------------------------------------------------------------------------
r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  changed a docstring.

------------------------------------------------------------------------
r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  adding this file to the project.

------------------------------------------------------------------------

Sally ser at hennes egen revisjon 344 forandrer seg, men ikke forandringen som du gjorde i revisjon 343. Hva Subversion angår, påvirket disse to innleggingene forskjellige filer på forskjellige plasseringer i depotet. Subversion viser imidlertid at de to filene deler en felles historie. Før grenkopieringen ble gjort i revisjon 341 var de den samme filen. Det er derfor både du og Sally ser forandringene gjort i revisjonene 303 og 98.

Det er to viktige ting du bør huske fra denne seksjonen.

I den forrige seksjonen nevnte vi at både du og Sally gjorde forandringer til integer.c på forskjellige forgreninger. Hvis du ser på Sallys loggmelding for revisjon 344, kan du se at hun forandret noen stavefeil. Din kopi av den samme filen har uten tvil de samme skrivefeilene. Det er sannsynlig at dine fremtidige forandringer i denne filen vil påvirke de samme områdene som skrivefeilene ligger i, så du ligger an til å få potensielle konflikter når du en vakker dag fletter inn grenen din. Da er det bedre å motta Sallys forandringer nå, før du starter med å arbeide mye i det samme området.

Det er på tide å bruke kommandoen svn merge. Det skal vise seg at denne kommandoen er en veldig nær slektning av svn diff-kommandoen (som du leste om i kapittel 3). Begge kommandoene er i stand til å sammenligne to vilkårlige objekter i depotet og beskrive forskjellene. For eksempel kan du spørre svn diff om å vise deg den eksakte forandringen gjort av Sally i revisjon 344:

$ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk

Index: integer.c
===================================================================
--- integer.c	(revision 343)
+++ integer.c	(revision 344)
@@ -147,7 +147,7 @@
     case 6:  sprintf(info->operating_system, "HPFS (OS/2 or NT)"); break;
     case 7:  sprintf(info->operating_system, "Macintosh"); break;
     case 8:  sprintf(info->operating_system, "Z-System"); break;
-    case 9:  sprintf(info->operating_system, "CPM"); break;
+    case 9:  sprintf(info->operating_system, "CP/M"); break;
     case 10:  sprintf(info->operating_system, "TOPS-20"); break;
     case 11:  sprintf(info->operating_system, "NTFS (Windows NT)"); break;
     case 12:  sprintf(info->operating_system, "QDOS"); break;
@@ -164,7 +164,7 @@
     low = (unsigned short) read_byte(gzfile);  /* read LSB */
     high = (unsigned short) read_byte(gzfile); /* read MSB */
     high = high << 8;  /* interpret MSB correctly */
-    total = low + high; /* add them togethe for correct total */
+    total = low + high; /* add them together for correct total */
 
     info->extra_header = (unsigned char *) my_malloc(total);
     fread(info->extra_header, total, 1, gzfile);
@@ -241,7 +241,7 @@
      Store the offset with ftell() ! */
 
   if ((info->data_offset = ftell(gzfile))== -1) {
-    printf("error: ftell() retturned -1.\n");
+    printf("error: ftell() returned -1.\n");
     exit(1);
   }
 
@@ -249,7 +249,7 @@
   printf("I believe start of compressed data is %u\n", info->data_offset);
   #endif
   
-  /* Set postion eight bytes from the end of the file. */
+  /* Set position eight bytes from the end of the file. */
 
   if (fseek(gzfile, -8, SEEK_END)) {
     printf("error: fseek() returned non-zero\n");

Kommandoen svn merge gjør omtrent nøyaktig det samme. Istedenfor å skrive forskjellene til terminalen din, blir de lagt direkte til arbeidskopien din som lokale modifikasjoner:

$ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
M  integer.c

Utdataene fra svn merge viser at din kopi av integer.c ble patchet. Nå inneholder den Sallys forandring – forandringen er blitt “kopiert” fra trunk til din arbeidskopi på din private gren, og eksisterer nå som en lokal modifisering. På dette punktet er det opp til deg å se over den lokale modifiseringen og forsikre deg om at den fungerer korrekt.

I et annet scenario er det mulig at ting ikke gikk så bra og at integer.c gikk inn i en konflikttilstand. Du må kanskje løse konflikten ved hjelp av standard prosedyrer (se kapittel 3), eller hvis du finner ut at flettingen egentlig var en dårlig idé, kan du rett og slett gi opp og kjøre svn revert på den lokale forandringen.

Men hvis vi går ut i fra at du har sett over forandringen, kan du bruke svn commit til å legge inn forandringen på vanlig måte. På dette tidpunktet er forandringen blitt flettet inn i din depotgren. I versjonskontrollterminologi blir denne måten å kopiere forandringer mellom forgreninger på engelsk kalt porting. Det finnes ikke en standardisert betegnelse for dette på norsk, så vi bruker i denne boken uttrykket “flette”.

Når du legger inn de lokale modifiseringene, bør du forsikre deg om at loggmeldingen din nevner at du fletter en forandring fra en gren til en annen. For eksempel:

$ svn commit -m "integer.c: Flettet r344 (retting av skrivefeil) fra trunk."
Sending        integer.c
Transmitting file data .
Committed revision 360.

Som du vil se i de neste seksjonene, er dette en veldig viktig “god praksis” å følge.

$ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk > patchfil
$ patch -p0  < patchfile
Patching file integer.c using Plan A...
Hunk #1 succeeded at 147.
Hunk #2 succeeded at 164.
Hunk #3 succeeded at 241.
Hunk #4 succeeded at 249.
done

En liten advarsel: Selv om svn diff og svn merge er veldig like i konsept, har de i mange tilfeller forskjellig syntaks. Vær sikker på at du får lest om dem i kapittel 9 for detaljer, eller spør svn help. For eksempel krever svn merge en arbeidskopi som et mål, det vil si en plass hvor den skal legge inn treforandringene. Hvis målet ikke er spesifisert, går den ut i fra at du prøver å utføre en av de følgende operasjonene:

Hvis du fletter en katalog og ikke har spesifisert en målsti, går svn merge ut i fra det første tilfellet og prøver å legge inn forandringene til den gjeldende katalogen. Hvis du fletter en fil, og denne filen (eller en fil med det samme navnet) eksisterer i den gjeldende katalogen, går svn merge ut i fra det andre tilfellet og forsøker å legge inn forandringene til en lokal fil med det samme navnet.

Hvis du vil legge inn forandringer en annen plass, må du si fra om dette. Hvis du for eksempel sitter i foreldrekatalogen til arbeidskopien din, må du spesifisere målkatalogen som skal motta forandringene:

$ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk my-calc-branch
U   my-calc-branch/integer.c

Du har nå sett et eksempel på svn merge-kommandoen, og du skal få se flere. Hvis du er forvirret omkring hvordan fletting faktisk virker, er du ikke alene om det. Mange brukere (spesielt de som er nye innen versjonskontroll) er usikker på den riktige syntaksen til kommandoen, og når denne funksjonaliteten skal brukes. Men frykt ikke, denne kommandoen er faktisk mye enklere enn du tror! Det er en veldig enkel teknikk for å forstå nøyaktig hvordan svn merge virker.

Hovedkilden til forvirringen er navnet på kommandoen. Terminologien merge – “flette” – indikerer på en måte at grener blir kombinert sammen, eller at det er en form for mystisk sammenblanding av data som foregår. Det er ikke tilfellet. Et bedre navn for kommandoen hadde vært svn diff-and-apply – “finn forskjell og legg denne til” – fordi det er alt som skjer: To depottrær blir sammenlignet, og forskjellene blir lagt inn i arbeidskopien.

Kommandoen tar tre argumenter:

Når disse tre argumentene er spesifisert, blir de to trærne sammenlignet og de forskjellene som programmet finner blir lagt inn i mål-arbeidskopien som lokale forandringer. Når kommandoen er ferdig, er ikke resultatet forskjellig fra om du hadde redigert filene for hånd, eller selv kjørt diverse svn add eller svn delete-kommandoer. Hvis du ikke liker resultatene, kan du enkelt kjøre svn revert for å omgjøre alle forandringene.

Syntaksen til svn merge lar deg spesifisere de tre nødvendige argumentene ganske fleksibelt. Her er noen eksempler:

$ svn merge http://svn.example.com/repos/branch1@150 \
            http://svn.example.com/repos/branch2@212 \
            min-arbeidskopi

$ svn merge -r 100:200 http://svn.example.com/repos/trunk min-arbeidskopi

$ svn merge -r 100:200 http://svn.example.com/repos/trunk

Den første syntaksen legger spesifikt opp alle tre argumentene, ved å nevne hvert tre på formen URL@REV og nevne arbeidskopimålet. Den andre syntaksen kan bli brukt som en snarvei for situasjoner når du sammenligner to forskjellige revisjoner på den samme URLen. Den siste syntaksen viser hvordan arbeidskopiargumentet er valgfritt; hvis det er utelatt, brukes den gjeldende katalogen.

For å fullføre eksempelet vårt vil vi nå reise fram i tiden. Tenk deg at flere dager har gått, og mange forandringer har skjedd både i trunk og på den private grenen din. Tenk deg så at du er ferdig med arbeidet på den private grenen; funksjonaliteten eller feilrettingen er endelig fullført, og nå vil du flette alle forandringene fra grenen din til trunk så andre kan få glede av dem.

Så hvordan bruker vi svn merge i dette tilfellet? Husk at denne kommandoen sammenligner to trær og legger forandringene inn i en arbeidskopi. For å motta forandringene må du derfor ha en arbeidskopi av trunk. Vi går ut i fra at du enten har den originale liggende (helt oppdatert), eller at du nylig hentet ut en fersk arbeidskopi av /calc/trunk.

Men hvilke to trær skal sammenlignes? Ved første øyekast ser det innlysende ut: Bare sammenlign seneste treet fra trunk med det seneste treet fra forgreningen. Men pass på – denne antakelsen er feil, noe som mange nye brukere har brent seg på. Siden svn merge opererer på samme måte som svn diff, vil en sammenligning mellom trærne i nyeste trunk og gren ikke bare vise forandringene som du har gjort på grenen. En slik sammenligning viser alt for mange forandringer: Den vil ikke bare vise tilleggingene av dine forandringer på grenen, men også fjerningen av forandringer i trunk som aldri skjedde på din gren.

For å bare vise forandringene som skjedde på din gren, må du sammenligne tilstanden ved starten av grenen din i forhold til dens endelige tilstand. Ved å bruke svn log på grenen kan du se at den ble opprettet i revisjon 341. Og den endelige tilstanden får du ved å bruke HEAD-revisjonen. Dette betyr at du vil sammenligne revisjonene 341 og HEAD i forgreningskatalogen og legge disse forskjellene inn i en arbeidskopi av trunk.

$ svn log --verbose --stop-on-copy \
          http://svn.example.com/repos/calc/branches/my-calc-branch
…
------------------------------------------------------------------------
r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   A /calc/branches/my-calc-branch (from /calc/trunk:340)

$

Her er den siste fletteprosedyren, og deretter:

$ cd calc/trunk
$ svn update
At revision 405.

$ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch
U   integer.c
U   button.c
U   Makefile

$ svn status
M   integer.c
M   button.c
M   Makefile

# … Undersøk forskjellene, kompiler, test osv …

$ svn commit -m "Flettet forandringer mellom r341:405 fra my-calc-branch til trunk."
Sending        integer.c
Sending        button.c
Sending        Makefile
Transmitting file data ...
Committed revision 406.

Igjen, legg merke til at loggmeldingen veldig spesifikt nevner området av forandringer som ble flettet inn på trunk. Husk alltid å gjøre dette, fordi det er vital informasjon som du vil trenge senere.

For eksempel, tenk at du bestemmer deg for å fortsette arbeidet på grenen en uke til, for å fullføre feilrettingen eller en forbedring av den originale funksjonaliteten. Depotets HEAD-revisjon er nå 480, og du er klar til å utføre en ny fletting fra den private grenen din til trunk. Men som diskutert i “Beste praksiser for fletting” vil du ikke flette forandringene du allerede har flettet før; du vil bare flette alt “nytt” på grenen siden forrige gang du flettet. Trikset er å finne ut hva som er nytt.

Første skritt er å kjøre svn log på trunk og se etter en loggmelding fra forrige gang du flettet fra grenen:

$ cd calc/trunk
$ svn log
…
------------------------------------------------------------------------
r406 | bruker | 2004-02-08 11:17:26 -0600 (Sun, 08 Feb 2004) | 1 line

Flettet forandringer mellom r341:405 fra my-calc-branch til trunk.
------------------------------------------------------------------------
…

Aha! Siden alle grenforandringene som skjedde mellom revisjonene 341 og 405 ble flettet til trunk som revisjon 406, vet du nå at du bare vil flette grenforandringene etter dette – ved å sammenligne revisjonene 406 og HEAD.

$ cd calc/trunk
$ svn update
At revision 480.

# Vi ser at HEAD er 480 for øyeblikket, så vi bruker den for å utføre 
# flettingen:

$ svn merge -r 406:480 http://svn.example.com/repos/calc/branches/my-calc-branch
U   integer.c
U   button.c
U   Makefile

$ svn commit -m "Flettet forandringer mellom r406:480 fra my-calc-branch til trunk."
Sending        integer.c
Sending        button.c
Sending        Makefile
Transmitting file data ...
Committed revision 481.

Nå inneholder trunk alle forandringene som ble gjort i den andre omgangen på grenen. På dette punktet kan du enten slette grenen (dette vil vi komme tilbake til) eller fortsette arbeidet på grenen og repetere denne prosedyren for etterfølgende flettinger.

En annen vanlig bruksmåte for svn merge er å omgjøre en forandring som allerede er blitt lagt inn. Tenk deg at du jobber glad og fornøyd på en arbeidskopi av /calc/trunk, og plutselig finner ut at forandringen du gjorde langt tilbake i revisjon 303, som forandret integer.c, er helt feil. Den skulle aldri vært lagt inn. Du kan bruke svn merge for å “angre” forandringen i arbeidskopien din, og deretter legge inn de lokale forandringene til depotet. Alt du trenger å gjøre er å spesifisere en omvendt forskjell:

$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
M  integer.c

$ svn diff
…
# Sjekk at forandringen er fjernet
…

$ svn commit -m "Fjernet forandringen som ble lagt inn i r303."
Sending        integer.c
Transmitting file data .
Committed revision 350.

En måte å tenke på en depotrevisjon er som en spesifikk gruppe av forandringer (noen versjonskontrollsystemer kaller disse forandringssett – changesets). Ved å bruke -r-valget kan du be svn merge om å legge inn et forandringssett, eller et helt område av forandringssett, vi ber svn merge om å legge inn forandringssett nummer 303 baklengs inn i arbeidskopien vår.

Husk at det å rulle tilbake en forandring som dette er akkurat likt enhver annen svn merge-operasjon, så du bør bruke svn status og svn diff for å forsikre deg om at arbeidet ditt er i den tilstanden du vil det skal være i, og deretter bruke svn commit for å sende den endelige versjonen til depotet. Etter innleggingen er dette spesielle forandringssettet ikke lenger representert i HEAD-revisjonen.

Og så tenker du kanskje: Nåh, dette omgjorde vel egentlig ikke innleggingen? Forandringen eksisterer fortsatt i revisjon 303. Hvis noen henter ut en versjon av calc-prosjektet mellom revisjonene 303 og 349, vil de se den gale forandringen, ikke sant?

Ja, det stemmer. Når vi snakker om å “fjerne” en forandring, snakker vi egentlig om å fjerne den fra HEAD. Den originale forandringen eksisterer fortsatt i depotets historie. I de fleste situasjoner er dette greit nok. De fleste er bare interessert i å følge HEAD av et prosjekt uansett. Det er imidlertid spesielle tilfeller du virkelig vil ødelegge alle spor etter innleggingen, kanskje la noen inn et konfidensielt dokument ved en ulykke. Dette er ikke så lett, viser det seg, fordi Subversion ble spesielt designet for å aldri miste informasjon. Revisjoner er uforanderlige trær som bygger på hverandre. Det å fjerne en revisjon fra historien vil forårsake en dominoeffekt som vil føre til kaos i alle etterfølgende revisjoner og muligens gjøre alle arbeidskopiene ubrukelige.^[9]

Det som er fint med versjonskontrollsystemer er at informasjon aldri går tapt. Selv om du sletter en fil eller katalog, kan den være borte fra HEAD-revisjonen, men objektet eksisterer fortsatt i tidligere revisjoner. Et av de vanligste spørsmålene nye brukere spør om, er: “Hvordan får jeg den gamle filen eller katalogen min tilbake?”.

Første skritt er å definere nøyaktig hvilket element du skal prøve å hente tilbake. Her er en nyttig metafor: Du kan tenke på hvert objekt i depotet som om det eksisterer i et slags todimensjonalt koordinatsystem. Det første koordinatet er et spesifikt revisjonstre, og det andre koordinatet er en sti inne i dette treet. Så hver versjon av filen eller katalogen din kan bli definert som et spesifikt koordinatpar.

Subversion har ingen Attic-katalog som CVS har,^[10] så du må bruke svn log for å finne det eksakte koordinatparet som du vil hente tilbake. En god strategi er å kjøre svn log --verbose i en katalog som inneholdt det slettede elementet ditt. Valget --verbose viser en liste over alle forandrede elementer i hver revisjon; alt du trenger å gjøre er å finne revisjonen der du slettet filen eller katalogen. Du kan gjøre dette visuelt, eller ved å bruke et annet verktøy for å undersøke utdataene fra loggen (ved hjelp av grep, eller kanskje ved hjelp av et inkrementelt søk i en tekstbehandler).

…
------------------------------------------------------------------------
r808 | joe | 2003-12-26 14:29:40 -0600 (Fri, 26 Dec 2003) | 3 lines
Changed paths:
   D /calc/trunk/real.c
   M /calc/trunk/integer.c

Added fast fourier transform functions to integer.c.
Removed real.c because code now in double.c.
…

I eksempelet går vi ut i fra at du ser etter en slettet fil kalt real.c. Ved å se gjennom loggene for en foreldrekatalog, har du funnet ut at denne filen ble slettet i revisjon 808. Derfor er den siste versjonen av filen der den fortsatt eksisterte i revisjonen like før dette. Konklusjon: Du vil hente tilbake stien /calc/trunk/real.c fra revisjon 807.

Dette var den vanskelige delen – etterforskningen. Nå som du vet hva du vil hente tilbake, har du to forskjellige valg.

En måte er å bruke svn merge for å legge inn revisjon 808 “i revers”. (Vi har allerede gått gjennom hvordan vi omgjør forandringer, se “Omgjøre forandringer”.) Dette vil ha samme effekten som å legge til real.c en gang til som en lokal modifisering. Filen vil bli klargjort for tillegging, og etter at du sender det inn til depotet med svn commit, vil filen atter en gang eksistere i HEAD.

Men i dette spesielle eksempelet er det kanskje ikke den beste strategien. Å legge inn revisjon 808 i revers vil ikke bare klargjøre real.c for tillegging, men loggmeldingen indikerer at det vil også bli omgjort forandringer i integer.c, noe som du ikke ønsker. Du kan selvfølgelig bakoverflette revisjon 808 og deretter kjøre svn revert på de lokale forandringene i integer.c, men denne teknikken skalerer ikke alltid like bra. Hva hvis det var 90 filer som forandret seg i revisjon 808?

En annen og mer målbevisst strategi er å ikke bruke svn merge i det hele tatt, men derimot svn copy. Kopier ganske enkelt den eksakte revisjonens og stiens “koordinatpar” fra depotet til arbeidskopien din:

$ svn copy --revision 807 \
           http://svn.example.com/repos/calc/trunk/real.c ./real.c

$ svn status
A  +   real.c

$ svn commit -m "Resurrected real.c from revision 807, /calc/trunk/real.c."
Adding         real.c
Transmitting file data .
Committed revision 1390.

Plusstegnet som vises i statusoversikten indikerer at elementet ikke bare er klargjort for tillegging, men er klargjort for tillegging “med historie”. Subversion husker hvor det ble kopiert fra. I framtiden vil kjøring av svn log på denne filen gå tilbake forbi gjenoppstandelsen av filen og gjennom hele historien den hadde før revisjon 807. Med andre ord, denne nye real.c er ikke egentlig ny; den er en direkte etterkommer av den originale, slettede filen.

Selv om eksempelet vårt viser at vi henter tilbake en fil, legg merke til at disse samme teknikkene virker like godt når det gjelder å hente tilbake slettede kataloger.

Versjonskontroll blir vanligvis brukt til programutvikling, så her er en rask kikk på to av de vanligste forgrenings-/flettemønstere som blir brukt av programmeringsteam. Hvis du ikke bruker Subversion til programutvikling, kan du hoppe over denne seksjonen. Hvis du er en programutvikler som bruker versjonskontroll for første gang, følg nøye med, da disse fremgangsmåtene ofte blant erfarne brukere er ansett som de beste metodene. Disse prosessene er ikke spesifikke til Subversion; de kan brukes med ethvert versjonskontrollsystem. Men det kan hjelpe å se dem beskrevet i Subversionterminologi.

$ cd trunk-working-copy

$ svn update
At revision 1910.

$ svn merge http://svn.example.com/repos/calc/trunk@1910 \
            http://svn.example.com/repos/calc/branches/mybranch@1910
U  real.c
U  integer.c
A  newdirectory
A  newdirectory/newfile
…

Atter en gang kommer svn copy og redder situasjonen. Hvis du vil lage et øyeblikksbilde av /calc/trunk nøyaktig som den ser ut i HEAD-revisjonen, kan du lage en kopi av den:

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/tags/release-1.0 \
      -m "Tagging the 1.0 release of the 'calc' project."

Committed revision 351.

Dette eksempelet forutsetter at en /calc/tags-katalog allerede eksisterer. (Hvis den ikke gjør det, se svn mkdir.) Etter at kopieringen er fullført, vil den nye release-1.0-katalogen for alltid være et øyeblikksbilde av hvordan prosjektet så ut i HEAD-revisjonen på den tiden du lagde kopien. Selvfølgelig vil du være mer presis angående hvilken revisjon du kopierer, i tilfelle noen andre kan ha lagt inn forandringer til prosjektet mens du ikke så det. Så hvis du vet at revisjon 350 av /calc/trunk er nøyaktig det øeblikksbildet du ønsker, kan du spesifisere dette ved å angi -r 350 til svn copy-kommandoen.

Men vent nå litt: Er ikke denne prosedyren med opprettelse av merker den samme prosedyren som vi brukte da vi lagde en gren? Ja, faktisk er det det. I Subversion er det ingen forskjell mellom et merke og en gren. Begge er bare vanlige kataloger som er opprettet ved kopiering. Akkurat som med grener, den eneste grunnen til at en kopiert katalog er et “merke” er fordi mennesker har bestemt seg for å behandle det på denne måten: Så lenge ingen noen gang legger inn forandringer til katalogen, forblir den for alltid et øyeblikksbilde. Hvis noen begynner å legge inn forandringer til den, blir den en gren.

Hvis du administrerer et depot, er det to fremgangsmåter du kan bruke for å holde rede på merker. Den første fremgangsmåten er “ikke rør”: Som en del av reglene innen prosjektet, bestem hvor i depotet merkene skal ligge, og gjør det klart for alle brukere hvordan de skal behandle kataloger som de kopierer inn dit. (Det vil si, vær sikker på at de vet at nye innlegginger ikke skal skje der.) Den andre fremgangsmåten er mer paranoid: Du kan bruke et av aksesskontrollskriptene som følger med Subversion til å forhindre noen fra å gjøre noe annet enn å opprette nye kopier i merkeområdet (se Kapittel 6, Server Configuration). Den paranoide ruten er imidlertid vanligvis ikke nødvendig. Hvis en bruker legger inn en forandring til en merkekatalog, kan du enkelt og greit omgjøre forandringen som nevnt i den forrige seksjonen. Dette er versjonskontroll, tross alt.

Noen ganger vil du at “øyeblikksbildet” skal være mer komplisert enn en enkel katalog med en enkelt revisjon.

For eksempel, tenk deg at prosjektet ditt er mye større enn calc-eksempelet vårt: Det inneholder mange underkataloger og mange flere filer. Mens du holder på med arbeidet, bestemmer du deg kanskje for at du må lage en arbeidskopi som er beregnet på å ha en spesiell funksjonalitet og feilrettinger. Du kan oppnå dette ved å selektivt tilbakedatere filer eller kataloger til spesielle revisjoner (ved å bruke svn update -r i stor skala), eller ved å bytte om filer og kataloger til spesielle grener (ved hjelp av svn switch). Når du er ferdig, er arbeidskopien din et virvar av depotplasseringer fra forskjellige revisjoner. Men etter at du har kjørt noen tester, vet du at dette er akkurat sånn som du vil ha det.

På tide å lagre et øyeblikksbilde. Det å kopiere en URL til en annen vil ikke fungere her. I dette tilfellet ønsker du å lage et øyeblikksbilde av din eksakte arbeidskopi og lagre den i depotet. Heldigvis har svn copy faktisk fire forskjellige bruksmåter (som du kan lese om i kapittel 9), inkludert muligheten til å kopiere et tre av en arbeidskopi til depotet:

$ ls
my-working-copy/

$ svn copy my-working-copy http://svn.example.com/repos/calc/tags/mytag

Committed revision 352.

Nå er det en ny katalog i depotet, /calc/tags/mytag, som er et eksakt øyeblikksbilde av arbeidskopien din – blandede revisjoner, URLer og hele pakken.

Andre brukere har funnet interessante måter å bruke denne funksjonaliteten på. Noen ganger er det situasjoner hvor du har en dunge med lokale forandringer i arbeidskopien, og du vil at en kollega skal se på dem. Istedenfor å kjøre svn diff og sende patchfilen (som ikke vil fange opp treforandringer), kan du istedenfor bruke svn copy for å “sende” arbeidskopien til et privat område i depotet. Kollegaen din kan dermed enten hente ut en nøyaktig kopi av arbeidskopien din, eller bruke svn merge for å motta de eksakte forandringene dine.

Det er noen standardiserte, anbefalte måter å organisere et depot på. Mange lager en trunk-katalog for der “hovedlinjen” av utvikling foregår, 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 layoutene. 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 en layout til en annen er bare snakk om å en serie flyttinger på tjeneren; hvis du ikke liker måten ting er organisert i depotet, bare flytt katalogene rundt om kring.

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 han bli fortalt at arbeidskopien hans 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. For eksempel, tenk 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/my-calc-branch \
             -m "Removing obsolete branch of calc project."

Committed revision 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/my-calc-branch \
                  http://svn.example.com/repos/calc/branches/my-calc-branch

Committed revision 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 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/stable-1.0 \
         -m "Creating stable branch of calc project."

Committed revision 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 bare feilrettinger skal legges inn i /calc/branches/stable-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.

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 forafatter (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 fremtide. 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 Subversionutvilkere ofte referer til et depot som “det [versjonerte] filsystemet”, har de lagt seg til vanen med å refere til den sistnevnte typen depot som FSFS: Det vil si, det er 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 “offisielt” enn det andre, og programmer som aksesserer depotet er isolert fra denne implementasjonsdetaljen. Programmer har ingen formening om hvordan depotet lagrer data; de ser bare revisjons- og transaksjonstrær gjennom depotgrensesnittet.

Her er en tabell som gir en oversikt over forskjellene mellom depoter av typen Berkeley DB og FSFS. De neste seksjonene går inn i detalj.

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          pre-revprop-change.tmpl
post-revprop-change.tmpl  start-commit.tmpl
pre-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 Subversion-støttede programmer, 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 malfilen til en 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.

Foreløpig er det fem påhakninger som er lagt inn i Subversiondepotet:

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-tjeneren og mod_dav_svn, så denne brukeren er den samme som Apache kjører som. Selve påhakningen 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.

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 lå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 filen DB_CONFIG finnes i hver miljøkatalog, og leser valgene som er i denne filen for bruk med akkurat dette Berkeley-miljøet.

Berkeley-konfigurasjonsfilen for ditt depot ligger i miljøkatalogen db i depot/db/DB_CONFIG. Subversion oppretter selv denne filen når den lager resten av depotet. Filen inneholder innledningsvis noen standardvalg sammen med pekere til dokumentasjonen til Berkeley DB som ligger online så du kan lese om hva disse valgene gjør. Selvfølgelig kan du legge til alle støttede Berkeley DB-valg til DB_CONFIG-filen. Pass bare på at mens Subversion aldri prøver å lese eller forstå innholdet i filen 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.

Subversion har en håndfull programmer nyttige for å 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 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.
…

$ svnlook info /sti/til/depot
$ svnlook info /sti/til/depot --revision 19

$ svnlook youngest /sti/til/depot
19

$ svnlook info /sti/til/depot
sally
2002-11-04 09:29:13 -0600 (Mon, 04 Nov 2002)
27
Added the usual
Greek tree.

$ 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>

$ 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)
…

$ svndumpfilter help
general usage: svndumpfilter SUBCOMMAND [ARGS & OPTIONS ...]
Type "svndumpfilter help <subcommand>" for help on a specific subcommand.

Available subcommands:
   exclude
   include
   help (?, h)

/
   calc/
      trunk/
      branches/
      tags/
   calendar/
      trunk/
      branches/
      tags/
   spreadsheet/
      trunk/
      branches/
      tags/

$ svnadmin dump /path/to/repos > repos-dumpfile
* Dumped revision 0.
* Dumped revision 1.
* Dumped revision 2.
* Dumped revision 3.
…
$

$ cat repos-dumpfile | svndumpfilter include calc > calc-dumpfile
…
$ cat repos-dumpfile | svndumpfilter include calendar > cal-dumpfile
…
$ cat repos-dumpfile | svndumpfilter include spreadsheet > ss-dumpfile
…
$

Node-path: calc
Node-action: add
Node-kind: dir
Content-length: 0

$ svnadmin create calc; svnadmin load calc < calc-dumpfile
<<< Started new transaction, based on original revision 1
     * adding path : Makefile ... done.
     * adding path : button.c ... done.
…
$ svnadmin create calendar; svnadmin load calendar < cal-dumpfile
<<< Started new transaction, based on original revision 1
     * adding path : Makefile ... done.
     * adding path : cal.c ... done.
…
$ svnadmin create spreadsheet; svnadmin load spreadsheet < ss-dumpfile
<<< Started new transaction, based on original revision 1
     * adding path : Makefile ... done.
     * adding path : ss.c ... done.
…
$

…
Node-path: spreadsheet/Makefile
…

$ svnshell.py /sti/til/depot
<rev: 2 />$  help
Available commands:
  cat FILE     : dump the contents of FILE
  cd DIR       : change the current working directory to DIR
  exit         : exit the shell
  ls [PATH]    : list the contents of the current directory
  lstxns       : list the transactions available for browsing
  setrev REV   : set the current revision to browse
  settxn TXN   : set the current transaction to browse
  youngest     : list the youngest browsable revision number
<rev: 2 />$

<rev: 2 />$ ls
   REV   AUTHOR  NODE-REV-ID     SIZE         DATE NAME
----------------------------------------------------------------------------
     1    sally <     2.0.1>          Nov 15 11:50 A/
     2    harry <     1.0.2>       56 Nov 19 08:19 iota
<rev: 2 />$ cd A
<rev: 2 /A>$ ls
   REV   AUTHOR  NODE-REV-ID     SIZE         DATE NAME
----------------------------------------------------------------------------
     1    sally <     4.0.1>          Nov 15 11:50 B/
     1    sally <     a.0.1>          Nov 15 11:50 C/
     1    sally <     b.0.1>          Nov 15 11:50 D/
     1    sally <     3.0.1>       23 Nov 15 11:50 mu
<rev: 2 /A>$ cd D/G 
<rev: 2 /A/D/G>$ ls
   REV   AUTHOR  NODE-REV-ID     SIZE         DATE NAME
----------------------------------------------------------------------------
     1    sally <     e.0.1>       23 Nov 15 11:50 pi
     1    sally <     f.0.1>       24 Nov 15 11:50 rho
     1    sally <     g.0.1>       24 Nov 15 11:50 tau
<rev: 2 /A>$ cd ../..
<rev: 2 />$ cat iota
This is the file 'iota'.
Added this text in revision 2.

<rev: 2 />$ setrev 1; cat iota
This is the file 'iota'.

<rev: 1 />$ exit
$

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

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 til 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 en 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.

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, disse døde transaksjonene er bare skrot i depotet og tar opp ressurser.

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:

#!/bin/sh

### Generer informasjon om alle utestående transaksjoner i et 
### Subversiondepot.

SVNADMIN=/usr/local/bin/svnadmin
SVNLOOK=/usr/local/bin/svnlook

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
$

Vanligvis, hvis du ser en død transaksjon som ikke har noen loggmelding vedlagt, er dette et resultat av en oppdateringsoperasjon (eller noe i likhet med en oppdatering) som har feilet. Disse operasjonene bruker Subversiontransaksjoner under panseret for å simulere tilstanden til en arbeidskopi. Siden de aldri er ment å bli lagt inn i depotet, krever ikke Subversion en loggmelding for disse transaksjonene. Transaksjoner som har loggmeldinger vedlagt er omtrent helt sikkert mislykkede innlegginger av en eller annen type. I tillegg kan tidspunktet til en transaksjon 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 tilgangslogg, 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 er spesifikk til Berkeley DB, FSFS-depot har ingen ekstra data som kan ryddes opp i eller brukes om igjen.

Inntil nylig var de største synderene når det gjelder diskplass brukt av Subversiondepot loggfilene der Berkeley DB utfører sine forhåndsskrivinger før de aktuelle databasefilene modifiseres. Disse filene inneholder alle operasjonene som blir utført langs ruten å forandre databasen fra en tilstand til en annen – mens databasefilene avspeiler til enhver tid en viss tilstand, inneholder loggfilene alle de mange småforandringene langs veien mellom tilstander. Og derfor kan disse ø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 filen 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 en 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.

Som nevnt i “Berkeley DB”, kan et Berkeley DB-depot noen ganger bli etterlatt i en frosset tilstand hvis den 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.

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^[15] 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:

Denne prosedyren reparerer nesten ethvert tilfelle av låste databaser. Vær sikker 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 CPU-arkitektur, eller for å bytte mellom Berkeley DB- og FSFS-lagringsformat. Den anbefalte måten å gjøre dette på er relativt enkel:

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 en 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 nyttdepot < dumpfil
<<< 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) >>>

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 dumpfilen bli ganske stor – mye større enn selve depotet. Dette er fordi hver eneste versjon av hver fil blir representert som fulltekst i dumpfilen. 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 dumpfilen 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 dumpfilen! 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 ka 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 en 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 depot, 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 for å “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,^[16] skulle det være relativt enkelt å beskrive generelle sett med forandringer – ved å bruke dette filformatet. Faktisk bruker programmet cvs2svn.py (se “Konvertere et depot fra CVS til Subversion”) dumpformatet for å representere innholdet i et CVS-depot så dette innholdet kan bli flyttet 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 tilgangen for alle sammen – 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 på en regulær basis. 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 finkornede 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 til 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 bakuper lengre tid, fordi hver innlegging enten blir spilt av inn i dumpfilen 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.^[17] Og siden du kan forandre revisjonsegenskaper som går på tvers av den kronolgisk rekkefølgen – du kan forandre enhver egenskap til en revisjon til enhver tid – 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 andre ekstra finkornede mekanismer på plass (som 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 så mye som 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 er opprettet, 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 disse harde tider.

Selv om Subversion lar deg flytte rundt versjonerte filer og kataloger uten tap av informasjon, kan det forstyrre arbeidsflyten til de som ofte aksesserer depotet og forventer at ting er på sine respektive plasser. Prøv å se litt inn i fremtiden; planlegg på forhånd før du plasserer dataene dine under versjonskontroll. Ved å “legge opp” innholdet av depotene dine på en effektiv måte den første gangen, kan du forhindre en drøss med fremtidige hodepiner.

Det er noen få ting å tenke over når du setter opp Subversiondepoter. La oss anta at som depotadministrator, vil du være ansvarlig for å vedlikeholde versjonskontrollsystemet for flere prosjekter. Det første du må bestemme deg for er om du vil bruke et enkelt depot for flere prosjekter, om du vil gi hvert prosjekt sitt eget depot, eller en kombinasjon av disse løsningene.

Det er fordeler med å bruke et enkelt depot for flere prosjekter, først og fremst at du slipper duplisert vedlikehold. Et enkelt depot betyr at det er ett sett med påhakningsskript, én ting å ta backup av, én ting å dumpe og laste hvis Subversion kommer i en ny inkompatibel versjon og så videre. I tillegg kan du lett flytte data mellom prosjekter uten å miste historisk versjonsinformasjon.

Bakdelen med å bruke et enkelt depot er at forskjellige prosjekter kan ha forskjellige postlister eller forskjellige autentiserings- og autorisasjonskrav. Husk også at Subversion bruker globale revisjonsnumre i depotet. Noen liker ikke at selv om ingen forandringer er blitt gjort i deres prosjekt den senere tid, fortsetter likevel det yngste revisjonsnummeret å øke fordi andre prosjekter legger til nye revisjoner.

En kompromissløsning kan også bli brukt. For eksemel kan prosjekter bli gruppert sammen etter hvor relaterte de er til hverandre. Du kan ha noen få depoter med en håndfull prosjekter i hvert av dem. På denne måten kan prosjekter som kan komme til å dele data gjøre dette ganske enkelt, og etterhvert som nye revisjoner blir lagt til depotet, vet utviklerne at disse nye revisjonene ihvertfall er fjernt relaterte på en eller annen måte til alle som bruker dette depotet.

Etter å ha avgjort hvordan du vil organisere prosjektene i henhold til depotene, vil du kanskje tenke over kataloghierarkier i selve depotene. Fordi Subversion bruker vanlige katalogkopier til forgrening og merking (se Kapittel 4, Forgrening og fletting), anbefaler Subversionmiljløet at du velger en katalogplassering for hver prosjektrot – den “øverste” katalogen som inneholder data relatert til det prosjektet – og deretter oppretter tre kataloger under denne roten: trunk som er katalogen der hovedutviklingen av prosjektet foregår; branches som er en katalog som er ment for å lage diverse navngitte grener av hovedutviklingen; tags som er en katalog av grener som er laget, og kanskje ødelagt, men aldri forandret.

For eksempel kan depotet ditt se ut som dette:

/
   calc/
      trunk/
      tags/
      branches/
   calendar/
      trunk/
      tags/
      branches/
   spreadsheet/
      trunk/
      tags/
      branches/
   …

Legg merke til at det har ingenting å si hvor i depotet hver prosjektrot er. Hvis du har bare ett prosjekt per depot, er den logiske plassen å putte hver prosjektrot i roten av det prosjektets respektive depot. Hvis du har flere prosjekter, vil du kanskje ønske å arrangere dem i grupper innenfor depotet, kanskje legge prosjekter med likelydende mål eller delt kode i den samme underkatalogen, eller kanskje rett og slett gruppere dem alfabetisk. Et slikt system kan se ut som dette:

/
   utils/
      calc/
         trunk/
         tags/
         branches/
      calendar/
         trunk/
         tags/
         branches/
      …
   office/
      spreadsheet/
         trunk/
         tags/
         branches/
      …

Legg opp depotet ditt på den måten du synes passer best. Subversion forventer ikke eller påtvinger deg ikke en spesiell layout – hva Subversion angår, er en katalog en katalog en katalog. Ideelt sett skal du kunne velge det depotoppsettet som fyller behovet til folkene som arbeider på prosjektet som bor der.

Etter at du har bestemt deg for hvordan du vil arrangere prosjektene i depotet ditt, vil du sannsynligvis ønske å fylle depotet med dette oppsettet og de innledende prosjektdataene. Det er et par måter du kan gjøre dette i Subversion. Du kan bruke svn mkdir-kommandoen (se Kapittel 9, Subversion Complete Reference) for å opprette hver katalog i skjelettet av depotlayouten, en og en. En raskere måte å utføre den samme oppgaven på er å bruke kommandoen svn import (se “svn import”). Ved å først opprette layouten i en midlertidig plassering på harddisken, kan du importere hele katalogtreet inn i depotet i en enkelt innlegging:

$ mkdir tmpdir
$ cd tmpdir
$ mkdir projectA
$ mkdir projectA/trunk
$ mkdir projectA/branches
$ mkdir projectA/tags
$ mkdir projectB
$ mkdir projectB/trunk
$ mkdir projectB/branches
$ mkdir projectB/tags
…
$ svn import . file:///path/to/repos --message 'Initial repository layout'
Adding         projectA
Adding         projectA/trunk
Adding         projectA/branches
Adding         projectA/tags
Adding         projectB
Adding         projectB/trunk
Adding         projectB/branches
Adding         projectB/tags
…
Committed revision 1.
$ cd ..
$ rm -rf tmpdir
$

Du kan kontrollere resultatene etter importen ved å kjøre kommandoen svn list:

$ svn list --verbose file:///path/to/repos
      1 harry               May 08 21:48 projectA/
      1 harry               May 08 21:48 projectB/
…
$

Når du har skjelettet til oppsettet på plass, kan du begynne å importere selve prosjektdataene inn i depotet ditt, hvis noen slike data allerede eksisterer. Som sagt, det er flere måter å gjøre dette på. Du kan bruuke svn import-kommandoen. Du kan hente ut en arbeidskopi fra det nye depotet ditt, flytte og arrangere prosjektdataene inne i arbeidskopien og bruke svn add- og svn commit-kommandoene. Men når vi begynner å snakke om slike ting snakker vi ikke lengre om depotadministrasjon. Hvis du ikke allerede er kjent med svn-klientprogrammet, se Kapittel 3, Guidet tur.

The Subversion client spends most of its time managing working copies. When it needs information from a repository, however, it makes a network request, and the server responds with an appropriate answer. The details of the network protocol are hidden from the user; the client attempts to access a URL, and depending on the URL schema, a particular protocol is used to contact the server (see Depot-URLer). Users can run svn --version to see which URL schemas and protocols the client knows how to use.

When the server process receives a client request, it typically demands that the client identify itself. It issues an authentication challenge to the client, and the client responds by providing credentials back to the server. Once authentication is complete, the server responds with the original information the client asked for. Notice that this system is different from systems like CVS, where the client pre-emptively offers credentials (“logs in”) to the server before ever making a request. In Subversion, the server “pulls” credentials by challenging the client at the appropriate moment, rather than the client “pushing” them. This makes certain operations more elegant. For example, if a server is configured to allow anyone in the world to read a repository, then the server will never issue an authentication challenge when a client attempts to svn checkout.

If the client's network request writes new data to the repository (e.g. svn commit), then a new revision tree is created. If the client's request was authenticated, then the authenticated user's name is stored as the value of the svn:author property on the new revision (see “Uversjonerte egenskaper”). If the client was not authenticated (in other words, the server never issued an authentication challenge), then the revision's svn:author property is empty. ^[18]

Many servers are configured to require authentication on every request. This can become a big annoyance to users, who are forced to type their passwords over and over again.

Happily, the Subversion client has a remedy for this: a built-in system for caching authentication credentials on disk. By default, whenever the command-line client successfully authenticates itself to a server, it saves the credentials in the user's private runtime configuration area—in ~/.subversion/auth/ on Unix-like systems or %APPDATA%/Subversion/auth/ on Windows. (The runtime area is covered in more detail in “Runtime Configuration Area”.) Successful credentials are cached on disk, keyed on a combination of hostname, port, and authentication realm.

When the client receives an authentication challenge, it first looks for the appropriate credentials in the disk cache; if not present, or if the cached credentials fail to authenticate, then the client simply prompts the user for the information.

The security-paranoid people may be thinking to themselves, “Caching passwords on disk? That's terrible! You should never do that!” But please remain calm. First, the auth/ caching area is permission-protected so that only the user (owner) can read data from it, not the world at large. If that's still not safe enough for you, you can disable credential caching. To disable caching for a single command, pass the --no-auth-cache option:

$ svn commit -F log_msg.txt --no-auth-cache
Authentication realm: <svn://host.example.com:3690> example realm
Username:  joe
Password for 'joe':

Adding         newfile
Transmitting file data .
Committed revision 2324.

# password was not cached, so a second commit still prompts us

$ svn delete newfile
$ svn commit -F new_msg.txt
Authentication realm: <svn://host.example.com:3690> example realm
Username:  joe
[...]

Or, if you want to disable credential caching permanently, you can edit your runtime config file (located next to the auth/ directory). Simply set store-auth-creds to no, and no credentials will be cached on disk, ever.

[auth]
store-auth-creds = no

Sometimes users will want to remove specific credentials from the disk cache. To do this, you need to navigate into the auth/ area and manually delete the appropriate cache file. Credentials are cached in individual files; if you look inside each file, you will see keys and values. The svn:realmstring key describes the particular server realm that the file is associated with:

$ ls ~/.subversion/auth/svn.simple/
5671adf2865e267db74f09ba6f872c28        
3893ed123b39500bca8a0b382839198e
5c3c22968347b390f349ff340196ed39

$ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28

K 8
username
V 3
joe
K 8
password
V 4
blah
K 15
svn:realmstring
V 45
<https://svn.domain.com:443> Joe's repository
END

Once you have located the proper cache file, just delete it.

One last word about client authentication behavior: a bit of explanation about the --username and --password options is needed. Many client subcommands accept these options; however it is important to understand using these options does not automatically send credentials to the server. As discussed earlier, the server “pulls” credentials from the client when it deems necessary; the client cannot “push” them at will. If a username and/or password are passed as options, they will only be presented to the server if the server requests them. ^[19] Typically, these options are used when:

Here is a final summary that describes how a Subversion client behaves when it receives an authentication challenge:

If the client successfully authenticates by any of the methods listed above, it will attempt to cache the credentials on disk (unless the user has disabled this behavior, as mentioned earlier.)

There are a few different ways to invoke the svnserve program. If invoked with no options, you'll see nothing but a help message. However, if you're planning to have inetd launch the process, then you can pass the -i (--inetd) option:

$ svnserve -i
( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )

When invoked with the --inetd option, svnserve attempts to speak with a Subversion client via stdin and stdout using a custom protocol. This is the standard behavior for a program being run via inetd. The IANA has reserved port 3690 for the Subversion protocol, so on a Unix-like system you can add lines to /etc/services like these (if they don't already exist):

svn           3690/tcp   # Subversion
svn           3690/udp   # Subversion

And if your system is using a classic Unix-like inetd daemon, you can add this line to /etc/inetd.conf:

svn stream tcp nowait svnowner /usr/local/bin/svnserve svnserve -i

Make sure “svnowner” is a user which has appropriate permissions to access your repositories. Now, when a client connection comes into your server on port 3690, inetd will spawn an svnserve process to service it.

On a Windows system, third-party tools exist to run svnserve as a service. Look on Subversion's website for a list of these tools.

A second option is to run svnserve as a standalone “daemon” process. Use the -d option for this:

$ svnserve -d
$               # svnserve is now running, listening on port 3690

When running svnserve in daemon mode, you can use the --listen-port= and --listen-host= options to customize the exact port and hostname to “bind” to.

There's still a third way to invoke svnserve, and that's in “tunnel mode”, with the -t option. This mode assumes that a remote-service program such as RSH or SSH has successfully authenticated a user and is now invoking a private svnserve process as that user. The svnserve program behaves normally (communicating via stdin and stdout), and assumes that the traffic is being automatically redirected over some sort of tunnel back to the client. When svnserve is invoked by a tunnel agent like this, be sure that the authenticated user has full read and write access to the repository database files. (See Servers and Permissions: A Word of Warning.) It's essentially the same as a local user accessing the repository via file:/// URLs.

Once the svnserve program is running, it makes every repository on your system available to the network. A client needs to specify an absolute path in the repository URL. For example, if a repository is located at /usr/local/repositories/project1, then a client would reach it via svn://host.example.com/usr/local/repositories/project1 . To increase security, you can pass the -r option to svnserve, which restricts it to exporting only repositories below that path:

$ svnserve -d -r /usr/local/repositories
…

Using the -r option effectively modifies the location that the program treats as the root of the remote filesystem space. Clients then use URLs that have that path portion removed from them, leaving much shorter (and much less revealing) URLs:

$ svn checkout svn://host.example.com/project1
…

When a client connects to an svnserve process, the following things happen:

At the time of writing, the server only knows how to send a CRAM-MD5 ^[20] authentication challenge. In essence, the server sends a bit of data to the client. The client uses the MD5 hash algorithm to create a fingerprint of the data and password combined, then sends the fingerprint as a response. The server performs the same computation with the stored password to verify that the result is identical. At no point does the actual password travel over the network.

It's also possible, of course, for the client to be externally authenticated via a tunnel agent, such as SSH. In that case, the server simply examines the user it's running as, and uses it as the authenticated username. For more on this, see “SSH authentication and authorization”.

As you've already guessed, a repository's svnserve.conf file is the central mechanism for controlling authentication and authorization policies. The file has the same format as other configuration files (see “Runtime Configuration Area”): section names are marked by square brackets ([ and ]), comments begin with hashes (#), and each section contains specific variables that can be set (variable = value). Let's walk through this file and learn how to use them.

[general]
password-db = userfile
realm = example realm

[users]
harry = foopassword
sally = barpassword

[general]
password-db = userfile
realm = example realm

# anonymous users can only read the repository
anon-access = read

# authenticated users can both read and write
auth-access = write

[general]
password-db = userfile
realm = example realm

# anonymous users aren't allowed
anon-access = none

# authenticated users can both read and write
auth-access = write

svnserve's built-in authentication can be very handy, because it avoids the need to create real system accounts. On the other hand, some administrators already have well-established SSH authentication frameworks in place. In these situations, all of the project's users already have system accounts and the ability to “SSH into” the server machine.

It's easy to use SSH in conjunction with svnserve. The client simply uses the svn+ssh:// URL schema to connect:

$ whoami
harry

$ svn list svn+ssh://host.example.com/repos/project
harry@host.example.com's password:  *****

foo
bar
baz
…

In this example, the Subversion client is invoking a local ssh process, connecting to host.example.com, authenticating as the user harry, then spawning a private svnserve process on the remote machine running as the user harry. The svnserve command is being invoked in tunnel mode (-t) and its network protocol is being “tunneled” over the encrypted connection by ssh, the tunnel-agent. svnserve is aware that it's running as the user harry, and if the client performs a commit, the authenticated username will be attributed as the author of the new revision.

The important thing to understand here is that the Subversion client is not connecting to a running svnserve daemon. This method of access doesn't require a daemon, nor does it notice one if present. It relies wholly on the ability of ssh to spawn a temporary svnserve process, which then terminates when the network connection is closed.

When using svn+ssh:// URLs to access a repository, remember that it's the ssh program prompting for authentication, and not the svn client program. That means there's no automatic password caching going on (see “Client Credentials Caching”). The Subversion client often makes multiple connections to the repository, though users don't normally notice this due to the password caching feature. When using svn+ssh:// URLs, however, users may be annoyed by ssh repeatedly asking for a password for every outbound connection. The solution is to use a separate SSH password-caching tool like ssh-agent on a Unix-like system, or pageant on Windows.

When running over a tunnel, authorization is primarily controlled by operating system permissions to the repository's database files; it's very much the same as if Harry were accessing the repository directly via a file:/// URL. If multiple system users are going to be accessing the repository directly, you may want to place them into a common group, and you'll need to be careful about umasks. (Be sure to read “Supporting Multiple Repository Access Methods”.) But even in the case of tunneling, the svnserve.conf file can still be used to block access, by simply setting auth-access = read or auth-access = none.

You'd think that the story of SSH tunneling would end here, but it doesn't. Subversion allows you to create custom tunnel behaviors in your run-time config file (see “Runtime Configuration Area”.) For example, suppose you want to use RSH instead of SSH. In the [tunnels] section of your config file, simply define it like this:

[tunnels]
rsh = rsh

And now, you can use this new tunnel definition by using a URL schema that matches the name of your new variable: svn+rsh://host/path. When using the new URL schema, the Subversion client will actually be running the command rsh host svnserve -t behind the scenes. If you include a username in the URL (for example, svn+rsh://username@host/path) the client will also include that in its command (rsh username@host svnserve -t.) But you can define new tunneling schemes to be much more clever than that:

[tunnels]
joessh = $JOESSH /opt/alternate/ssh -p 29934

This example demonstrates a couple of things. First, it shows how to make the Subversion client launch a very specific tunneling binary (the one located at /opt/alternate/ssh) with specific options. In this case, accessing a svn+joessh:// URL would invoke the particular SSH binary with -p 29934 as arguments—useful if you want the tunnel program to connect to a non-standard port.

Second, it shows how to define a custom environment variable that can override the name of the tunneling program. Setting the SVN_SSH environment variable is a convenient way to override the default SSH tunnel agent. But if you need to have several different overrides for different servers, each perhaps contacting a different port or passing a different set of options to SSH, you can use the mechanism demonstrated in this example. Now if we were to set the JOESSH environment variable, its value would override the entire value of the tunnel variable—$JOESSH would be executed instead of /opt/alternate/ssh -p 29934.

It's not only possible to control the way in which the client invokes ssh, but also to control the behavior of sshd on your server machine. In this section, we'll show how to control the exact svnserve command executed by sshd, as well as how to have multiple users share a single system account.

  ssh-dsa AAAABtce9euch.... user@example.com

  command="program" ssh-dsa AAAABtce9euch.... user@example.com

  command="program" TYPE KEY COMMENT

  command="/path/to/svnserve -t -r /virtual/root" TYPE KEY COMMENT

  command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry@example.com
  command="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally@example.com

  command="svnserve -t --tunnel-user=harry",no-port-forwarding,\
           no-agent-forwarding,no-X11-forwarding,no-pty \
           TYPE1 KEY1 harry@example.com

To network your repository over HTTP, you basically need four components, available in two packages. You'll need Apache httpd 2.0, the mod_dav DAV module that comes with it, Subversion, and the mod_dav_svn filesystem provider module distributed with Subversion. Once you have all of those components, the process of networking your repository is as simple as:

You can accomplish the first two items either by compiling httpd and Subversion from source code, or by installing pre-built binary packages of them on your system. For the most up-to-date information on how to compile Subversion for use with the Apache HTTP Server, as well as how to compile and configure Apache itself for this purpose, see the INSTALL file in the top level of the Subversion source code tree.

Once you have all the necessary components installed on your system, all that remains is the configuration of Apache via its httpd.conf file. Instruct Apache to load the mod_dav_svn module using the LoadModule directive. This directive must precede any other Subversion-related configuration items. If your Apache was installed using the default layout, your mod_dav_svn module should have been installed in the modules subdirectory of the Apache install location (often /usr/local/apache2). The LoadModule directive has a simple syntax, mapping a named module to the location of a shared library on disk:

LoadModule dav_svn_module     modules/mod_dav_svn.so

Note that if mod_dav was compiled as a shared object (instead of stati