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 1.2, “Problemet som må unngås”. Sett at vi har to arbeidskolleger, Harry og Sally. De bestemmer seg begge for å redigere den samme fila 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 fila. Selv om Harrys versjon av fila 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 fila, fordi hun så aldri Harrys forandringer til å begynne med. Harrys arbeid er fortsatt borte – eller i det minste borte fra den siste versjonen av fila – og sannsynligvis ved en ulykke. Dette er definitivt en situasjon vi vil unngå!

Figur 1.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 problemet med at mange forfattere roter til hverandres arbeid. I denne modellen tillater depotet bare en person å forandre en fil om gangen. Denne eksklusive arbeidsmåten styres ved bruk av låser. Harry må “låse” ei fil før han kan begynne å gjøre forandringer i den. Hvis Harry har låst ei fil, kan ikke Sally også låse den, og kan derfor ikke gjøre noen forandringer i denne fila. Alt hun kan gjøre er å lese fila 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 fila kan Sally ta sin runde med å låse og redigere fila. Figur 1.3, ““Lås-rediger-lås opp”-løsningen” demonstrerer denne enkle løsningen.

Figur 1.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 en rekke 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 og uavhengig med å 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 fila 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, fil 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 fila, lagrer han sin egen arbeidskopi til depotet. Figur 1.4, ““Kopier-rediger-flett”-løsningen” og Figur 1.5, ““Kopier-rediger-flett”-løsningen (forts.)” viser denne prosessen.

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

Figur 1.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 fila 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 vanligvis 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.

Gjennom denne boka bruker Subversion URLer for å identifisere versjonerte ressurser i Subversion-depoter. For det meste bruker disse URLene standard syntaks, som tillater servernavn og portnummer å bli spesifisert som en del av URLen:

$ svn checkout http://svn.example.com:9834/repos
…

Men det er noen nyanser i Subversions behandling av URLer som legges merke til. For eksempel, URLer som bruker file:-aksesseringsmetoden (brukt for lokale depoter) må, i henhold til konvensjonene, enten ha servernavnet localhost eller ikke noe servernavn:

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

I tillegg må brukere av file:-skjemaet på MS Windows-plattformer bruke en uoffisiell “standard” syntaks for å aksessere depoter smo er på den samme maskinen, men på en annen disk enn klientens nåværende arbeidsdisk. En av de to følgende URL-syntaksene vil virke der X er disken hvor depotet ligger:

C:\> svn checkout file:///X:/sti/til/depot
…
C:\> svn checkout "file:///X|/sti/til/depot"
…

I den andre syntaksen må du sette URLen i hermetegn ("") så det vertikale stolpetegnet ikke blir tolket som et rør. Legg også merke til at en URL bruker vanlige skråstreker (/) selv om den lokale (ikke-URL) formen i en sti i MS Windows bruker omvendte skråstreker (\).

Til slutt må det legges merke til at Subversionklienten automatisk vil kode URLer etter behov, akkurat som en nettleser gjør det. For eksempel, hvis en URL inneholder et mellomrom eller store bokstaver:

$ svn checkout "http://server/sti med mellomrom/prosjekt/españa"

… så vil Subversion beskytte de usikre tegnene og oppføre seg som om du hadde skrevet:

$ svn checkout http://server/sti%20med%20mellomrom/prosjekt/espa%C3%B1a

Hvis URLen inneholder mellomrom, pass på å plassere den innenfor hermetegn, så skallet behandler hele URLen som et enkelt argument til svn-programmet.

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. Du kan til og med ha flere arbeidskopier av det samme prosjektet.

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 1.6, “Depotets filsystem”.

Figur 1.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/Makefile
A    calc/integer.c
A    calc/button.c
Checked out revision 56.

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

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 fila. 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 -m "Ordnet en skrivefeil i button.c ."
Sender        button.c
Sender fildata .
La inn revisjon 57.

Nå er dine forandringer til button.c lagt inn i depotet, med en melding som beskriver forandringen din (at du ordnet en skrivefeil). Hvis en annen bruker henter ut en arbeidskopi av /calc, vil de se dine forandringer i den seneste versjonen av fila.

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
Updated to revision 57.

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 publiserer forandringer til et vilkårlig 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 et komplett sett med forandringer som en atomisk transaksjon.

Med “atomisk transaksjon” mener vi rett og slett dette: Enten skjer alle forandringene i depotet, eller ingen av dem skjer. 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 1.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 1.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 fleksibilitet er muligheten til å ha en arbeidskopi som inneholder filer og kataloger med en blanding av forskjellige arbeidsrevisjonsnumre. Uheldigvis har denne fleksibiliteten en tendens til å forvirre en del nye brukere. Hvis det tidligere eksempelet som viser blandede revisjoner gjør deg litt perpleks, her kommer en forklaring på hvorfor denne funksjonaliteten finnes og hvordan du gjør bruk av den.

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
Oppdatert til revisjon 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 serveren 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).

	Advarsel
	Selv om du kan redigere filene dine med hvilket verktøy du vil, bør du ikke forandre strukturen i arbeidskopien uten å la Subversion vite hva du gjør. Bruk kommandoene svn copy, svn delete og svn move for å forandre strukturen på arbeidskopien, og bruk svn add-kommandoen for å legge inn nye filer og kataloger under versjonskontroll.

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 ei 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     en_katalog          # svn etterlot en lås i .svn-området for 
                            # en_katalog
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           # katalogen er del av en 
                            # «externals»-definering
?       foo.o               # svn kjenner ikke til foo.o
!       some_dir            # svn kontrollerer denne, men den mangler 
                            # eller er ikke komplett
~       qux                 # versjonert som fil/katalog/lenke, men 
                            # elementtypen er forandret
I       .screenrc           # svn kontrollerer ikke denne, og er satt 
                            # opp til å ignorere den
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        # fila er klargjort for sletting
A       stuff/loot/bloo.h   # fila er klargjort for tillegging
C       stuff/loot/lump.c   # fila har tekstmessige konflikter fra en 
                            # oppdatering
 C      stuff/loot/glub.c   # fila har konflikt i egenskapene fra en 
                            # oppdatering
R       xyz.c               # fila er klargjort for erstatning
    S   stuff/squawk        # fila eller katalogen er byttet til en 
                            # annen plassering i depotet ved hjelp av 
                            # svn switch-kommandoen
     K  dog.jpg             # fila er låst lokalt; låsnøkkel finnes
     O  cat.jpg             # fila er låst i depotet av en annen bruker
     B  bird.jpg            # fila er låst lokalt, men låsen er blitt 
                            # brutt
     T  fish.jpg            # fila er låst lokalt, men låsen er blitt 
                            # stjålet

$ 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 mot revisjon:   46

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

 int main(void) {
-  printf("Sekstifire skiver med amerikansk ost...\n");
+  printf("Sekstifem skiver med amerikansk ost...\n");
 return 0;
 }

Index: README
===================================================================
--- README	(revisjon 3)
+++ README	(arbeidskopi)
@@ -193,3 +193,4 @@ 
+Husk: Plukk opp skittentøyet.

Index: stuff/fish.c
===================================================================
--- stuff/fish.c	(revisjon 1)
+++ stuff/fish.c	(arbeidskopi)
-Velkommen til fila som er kjent som «fish».
-Det vil bli litt fiskeinfo her etterhvert.

Index: stuff/things/bloo.h
===================================================================
--- stuff/things/bloo.h	(revisjon 8)
+++ stuff/things/bloo.h	(arbeidskopi)
+Her er en ny fil for å fortelle
+ting om bloo.

$ svn diff > patchfil

svn revert

Tenk deg nå at du ser resultatet av diffen ovenfor, og oppdager at forandringene dine til README er en feil; kanskje du la denne teksten inn i feil fil ved en ulykke.

Dette er en perfekt mulighet til å bruke kommandoen svn revert.

$ svn revert README
Tilbakestilte «README»

Subversion reverserte fila til sin før-modifiserte tilstand ved å overskrive den med den lagrede “urørte” kopien fra .svn-området. Men legg også merke til at svn revert kan omgjøre alle klargjorte operasjoner – for eksempel kan du bestemme deg for at du likevel ikke vil legge til en ny fil:

$ svn status foo
?      foo

$ svn add foo
A         foo

$ svn revert foo
Tilbakestilte «foo»

$ svn status foo
?      foo

	Notat
	svn revert ELEMENT har nøyaktig den samme effekten som om du sletter ELEMENT fra arbeidskopien din og deretter kjører svn update -r BASE ELEMENT. Imidlertid, hvis du reverserer ei fil har svn revert en forskjell som er verdt å legge merke til – den trenger ikke å kommunisere med depotet for å legge tilbake fila di.

Eller kanskje du fjernet ei fil fra versjonskontroll ved en ulykke:

$ svn status README 
       README

$ svn delete README 
D         README

$ svn revert README
Tilbakestilte «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
Oppdatert til revisjon 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 fila 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 serveren 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 fila sandwich.txt i depotet. Harry har akkurat forandret fila 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
Oppdatert til revisjon 2.
$ ls -1
sandwich.txt
sandwich.txt.mine
sandwich.txt.r1
sandwich.txt.r2

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

$ svn commit --message "Legg til noen flere ting"
svn: Innsending feilet (detaljer følger):
svn: Avbryter innsending: «/home/sally/svn-work/sandwich.txt» er fortsatt i konflikt

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 fila for å være i konflikt.^[5]

$ svn resolved sandwich.txt
Konflikten i «sandwich.txt» er løst

$ 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 "Gå i gang med å bruke mitt smørbrød, bort med Sallys redigeringer."

$ svn update
C  sandwich.txt
Oppdatert til revisjon 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
Tilbakestilte «sandwich.txt»
$ ls sandwich.*
sandwich.txt

Endelig! Du er ferdig med forandringene dine, du har flettet inn alle forandringene fra serveren, 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 "Ordnet antall osteskiver."
Sender        sandwich.txt
Sender fildata .
La inn revisjon 3.

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

$ svn commit --file logmsg 
Sender        sandwich.txt
Sender fildata .
La inn revisjon 4.

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

	Tips
	Hvis du skriver en loggmelding i tekstbehandleren og bestemmer deg for å avbryte innleggingen, kan du bare avbryte uten å lagre endringene. Hvis du allerede har lagret innleggingsmeldingen, kan du slette teksten og lagre på nytt. $ svn commit Venter på Emacs...Ferdig Loggmeldingen er uforandret eller ikke spesifisert Avbryt (a), fortsett (c), rediger (e) 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 "La til en ny regel"
Sender        rules.txt
svn: Innsending feilet (detaljer følger):
svn: Utdatert: «rules.txt» i transaksjon «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 ei fil eller katalog, bruk kommandoen svn log. svn log vil gi deg en oversikt over hvem som gjorde forandringer i ei fil eller en 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 | man, 15 jul 2002 18:03:46 -0500 | 1 line

La til include-linjer og ordnet antall osteskiver.
------------------------------------------------------------------------
r2 | harry | man, 15 jul 2002 17:47:57 -0500 | 1 line

La til main()-metoder.
------------------------------------------------------------------------
r1 | sally | man, 15 jul 2002 17:40:08 -0500 | 1 line

Innledende 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 ei 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 arbeidsfila (eller URLen) forandret seg.

Hvis du vil ha enda mer informasjon om ei fil eller en 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 tar også et --quiet-parameter (-q) som lar være å skrive ut kroppen på loggmeldinga. Når det kombineres med --verbose lister det kun navnet på filene som har forandret seg.

$ 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	(revisjon 3)
+++ rules.txt	(arbeidskopi)
@@ -1,4 +1,5 @@
 Vær snill med andre
 Frihet = ansvar
 Alt med måte
-Tygg med munnen åpen
+Tygg med munnen lukket
+Hør etter når andre prater
$

$ svn diff --revision 3 rules.txt 
Index: rules.txt
===================================================================
--- rules.txt	(revisjon 3)
+++ rules.txt	(arbeidskopi)
@@ -1,4 +1,5 @@
 Vær snill med andre
 Frihet = ansvar
 Alt med måte
-Tygg med munnen åpen
+Tygg med munnen lukket
+Hør etter når andre prater
$

$ svn diff --revision 2:3 rules.txt 
Index: rules.txt
===================================================================
--- rules.txt	(revisjon 2)
+++ rules.txt	(revisjon 3)
@@ -1,4 +1,4 @@
 Vær snill med andre
-Frihet = sjokoladeis
+Frihet = ansvar
 Alt med måte
 Tygg med munnen åpen
$

$ 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 ei fil og ikke nødvendigvis forskjellene mellom to filer, kan du bruke svn cat:

$ svn cat --revision 2 rules.txt 
Vær snill med andre
Frihet = sjokoladeis
Alt med måte
Tygg med munnen åpen
$

Du kan også omdirigere utdataene direkte til ei 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 fila 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 ei fil ved å bruke et eksternt diffprogram (kanskje et grafisk et, eller kanskje fila di 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 ei fil, og angi både den og fila i arbeidskopien til det eksterne diffprogrammet.

For det andre er det noen ganger rett og slett lettere å se på en eldre versjon av en fil i sin helhet i stedet for bare å se på 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 fila eller katalogen sist ble modifisert, brukeren som gjorde det, størrelsen hvis det er ei 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”^[7]:

$ 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 loggfila for å utføre forandringen det blir bedt om mens det setter opp en lås på den relevante delen av arbeidskopien mens det arbeider – dette er for å hindre andre Subversionklienter fra å aksessere arbeidskopien midt under forandringer. Til slutt fjerner Subversion loggfila. Arkitekturmessig er dette likt et journalfilsystem. Hvis en Subversionoperasjon blir avbrutt (hvis prosessen blir drept eller maskinen krasjer, for eksempel), blir loggfila liggende på disken. Ved å utføre kommandoene i loggfila 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 i arbeidskopien 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

Du må ikke forveksle disse arbeidskopilåsene med de vanlige låsene som Subversionbrukere oppretter når de bruker “lås-modifiser-lås opp”-versjonskontrollmodellen; se Three meanings of “lock” for forklaring på dette.

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/et/prosjekt \
             -m "Innledende import"
Legger til         mitt_tre/foo.c
Legger til         mitt_tre/bar.c
Legger til         mitt_tre/subdir
Legger til         mitt_tre/subdir/quux.h

La inn revisjon 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.

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:

As can be derived from their descriptions, the PREV, BASE, and COMMITTED revision keywords are used only when referring to a working copy path—they don't apply to repository URLs. HEAD, on the other hand, can be used in conjuction with both of these path types.

Her er noen eksempler på revisjonsnøkkelord i aksjon:

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

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

$ svn diff -r HEAD
# sammenligner arbeidskopien din (med alle lokale forandringer) med den 
# seneste versjonen av det treet i depotet

$ svn diff -r BASE:HEAD foo.c
# sammenligner den umodifiserte versjonen av foo.c mot den seneste 
# versjonen av foo.c i depotet

$ svn log -r BASE:HEAD
# viser alle loggmeldinger for den nåværende versjonerte katalogen siden 
# du sist oppdaterte

$ svn update -r PREV foo.c
# omgjør den nyeste forandringen i foo.c og minsker arbeidsrevisjonen 
# for foo.c

$ svn diff -r BASE:14 foo.c
# sammenligner den umodifiserte versjonen av foo.c med det foo.c var i 
# revisjon 14

Revision numbers reveal nothing about the world outside the version control system, but sometimes you need to correlate a moment in real time with a moment in version history. To facilitate this, the --revision option can also accept as input date specifiers wrapped in curly braces ({ and }). Subversion accepts the standard ISO-8601 date and time formats, plus a few others. Here are some examples. (Remember to use quotes around any date that contains spaces.)

$ svn checkout -r {2006-02-17}
$ svn checkout -r {15:30}
$ svn checkout -r {15:30:00.200000}
$ svn checkout -r {"2006-02-17 15:30"}
$ svn checkout -r {"2006-02-17 15:30 +0230"}
$ svn checkout -r {2006-02-17T15:30}
$ svn checkout -r {2006-02-17T15:30Z}
$ svn checkout -r {2006-02-17T15:30-04:00}
$ svn checkout -r {20060217T1530}
$ svn checkout -r {20060217T1530Z}
$ svn checkout -r {20060217T1530-0500}
…

When you specify a date, Subversion resolves that date to the most recent revision of the repository as of that date, and then continues to operate against that resolved revision number:

$ svn log -r {2006-11-28}
------------------------------------------------------------------------
r12 | ira | 2006-11-27 12:31:51 -0600 (man, 27 nov 2006) | 6 lines
…

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

$ svn log -r {2006-11-20}:{2006-11-29}
…

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

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

	Advarsel
	Siden tidspunktet på en revisjon er lagret som en uversjonert, redigerbar egenskap for revisjonen (se “Egenskaper”, kan revisjonsegenskaper bli forandret til å representere en kronologi som ikke stemmer, eller kan til og med bli fjernet helt. Dette vil rote til den interne “dato-til-revisjon”-konverteringen som Subversion utfører.

Akkurat som Subversion bruker egenskaper for å lagre ekstra informasjon om filer, kataloger og revisjoner som den inneholder, kan du også få god bruk for egenskaper. Noen deler av prosessene rundt bruken din av Subversion, eller kanskje tilleggsprogrammer til Subversion som du bruker, kan få nytte av å ha en plass nær dine versjonerte data der du kan legge spesialsydde metadata om disse dataene.

Tenk deg at du vil sette opp en hjemmeside som inneholder mange digitale bilder, og viser dem med tittel og tidspunkt. Fotosamlingen forandrer seg i ett sett, så du vil helst automatisere så mye som mulig. Disse bildene kan være ganske store, så du vil i likhet med andre hjemmesider av denne typen vise miniatyrbilder til de besøkende.

Nå kan du saktens oppnå denne effekten ved å bruke tradisjonelle filer. Det vil si at du kan ha bildet bilde123.jpg og en bilde123-mini.jpg side ved side i en katalog. Eller hvis du vil bruke det samme filnavnet, kan du ha miniatyrbildene i en annen katalog, for eksempel mini/bilde123.jpg. Du kan også lagre titlene og tidspunktene på en lignende måte, separert fra den originale bildefila. Men problemet her er at samlingen din av filer vokser noe voldsomt for hvert nytt bilde som blir lagt til hjemmesida.

Så kan du se for deg den samme hjemmesida lagt opp på en måte som bruker Subversions filegenskaper. Tenk deg å ha en enkelt bildefil, bilde123.jpg, med egenskaper på denne fila som er kalt tittel, tidspunkt og miniatyr. Nå ser arbeidskopien din mye mer oversiktlig ut – faktisk ser det med en vanlig nettleser ut som det bare er bildefiler i den. Men de automatiserte skriptene dine vet bedre. De vet at de kan bruke svn (eller enda bedre, de kan bruke språkbindingene i Subversion – se “Using Languages Other than C and C++”) for å hente ut den ekstra informasjonen som hjemmesida trenger for å vise bildet uten å måtte lese en indeksfil eller trikse med filstier.

Spesialsydde revisjonsegenskaper blir også ofte brukt. En vanlig bruksmåte er en egenskap der verdien inneholder en ID fra en feildatabase som revisjonen er assosiert med, kanskje fordi forandringen i den revisjonen ordner en feil som er logget i feildatabasen med den ID-en. Andre bruksmåter kan være å legge ved mer brukervennlige navn i revisjonen – det kan være vanskelig å huske at revisjon 1935 var en gjennomtestet revisjon. Men hvis det er, la oss si, en testresultat-egenskap på den revisjonen med en verdi som Alt OK, er det god informasjon å ha.

Issue(s): IZ2376, IZ1919
Reviewed by:  sally

This fixes a nasty segfault in the wort frabbing process
…

svn-kommandoen har flere måter å legge til og modifisere fil- og katalogegenskaper. For egenskaper med korte egenskaper som er leselig for folk flest, er kanskje den enkleste måten å legge til en ny egenskap å spesifisere navnet på egenskapen med verdien dens på kommandolinja med propset-delkommandoen.

$ svn propset copyright '(c) 2006 Red-Bean Software' calc/button.c
Egenskapen «copyright» satt på «calc/button.c»
$

Men vi har fremhevet fleksibiliteten som Subversion har for egenskapsverdier. Og hvis du har en tekstbasert, eller til og med binær egenskapsverdi som går over flere linjer, vil du sannsynligvis ikke oppgi denne verdien på kommandolinja. Derfor kan propset-delkommandoen bruke valget --file (-F) for å spesifisere navnet på en fil som inneholder den nye verdien til egenskapen.

$ svn propset license -F /sti/til/LISENS calc/button.c
Egenskapen «license» satt på «calc/button.c»
$

Det er noen restriksjoner på navnene du kan bruke på egenskaper. Et egenskapsnavn må starte med en bokstav, kolon (:) eller understrek (_). Etter dette kan du også bruke siffer, bindestrek (-) og punktum (.).^[8]

I tillegg til propset-kommandoen, har svn-programmet kommandoen propedit. Denne kommandoen bruker tekstbehandleren som er spesifisert i konfigurasjonen (se “Konfigurasjon”) for å legge til eller modifisere egenskaper. Når du kjører kommandoen, kjører svn tekstbehandleren mot en midlertidig fil som inneholder den nåværende verdien til egenskapen (eller starter uten tekst hvis du legger til en ny egenskap). Deretter forandrer du på verdien i tekstbehandleren til den er lik den nye verdien du vil lagre i egenskapen, lagrer den midlertidige fila og avslutter tekstbehandleren. Hvis Subversion finner ut at du faktisk har forandret den nåværende egenskapsverdien, vil den godta det som den nye verdien til egenskapen. Hvis du avslutter tekstbehandleren uten å gjøre noen forandringer, vil det ikke bli gjort noen forandringer i egenskapen.

$ svn propedit copyright calc/button.c
### tekstbehandleren avsluttes uten at noe er forandret
Ingen endring for egenskap «copyright» på «calc/button.c»
$

Vi skal legge merke til at i likhet med andre svn-kommandoer kan de som har med egenskaper å gjøre utføre handlinger på flere stier på en gang. Dette lar deg forandre egenskaper på hele sett av filer med en enkelt kommando. For eksempel kunne vi ha gjort dette:

$ svn propset copyright '(c) 2006 Red-Bean Software' calc/*
Egenskapen «copyright» satt på «calc/Makefile»
Egenskapen «copyright» satt på «calc/button.c»
Egenskapen «copyright» satt på «calc/integer.c»
…
$

Alt dette med å legge til og redigere egenskaper hadde egentlig ikke vært særlig nyttig hvis du ikke hadde hatt en måte å få tak i den lagrede egenskapsverdien. Til dette har svn-programmet to delkommandoer for å vise navnene og verdiene til egenskaper som er lagret i filer og kataloger. Kommandoen svn proplist vil liste ut navnene på egenskapene som eksisterer i en sti. Når du vet navnene til egenskapene på noden, kan du be om verdiene individuelt ved å bruke svn propget. Denne kommandoen vil, når den får en sti (eller sett av stier) og et egenskapsnavn, skrive verdien av egenskapen til standard ut-strømmen.

$ svn proplist calc/button.c
Egenskaper for «calc/button.c»:
  copyright
  license
$ svn propget copyright calc/button.c
(c) 2006 Red-Bean Software

Det er til og med en variant av proplist-kommandoen som vil liste både navnet og verdien til alle egenskapene. Bare legg til valget --verbose (-v).

$ svn proplist --verbose calc/button.c
Egenskaper for «calc/button.c»:
  copyright : (c) 2006 Red-Bean Software
  license : ================================================================
Copyright (c) 2006 Red-Bean Software.  All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions 
are met:

1. Redistributions of source code must retain the above copyright
notice, this list of conditions, and the recipe for Fitz's famous
red-beans-and-rice.
…

Den siste delkommandoen relatert til egenskaper er propdel. Siden Subversion lar deg lagre egenskaper med tomme verdier, kan du ikke fjerne en egenskap helt ved å bruke propedit eller propset. For eksempel, denne kommandoen vil ikke gjøre det du ønsker:

$ svn propset license '' calc/button.c
Egenskapen «license» satt på «calc/button.c»
$ svn proplist --verbose calc/button.c
Egenskaper for «calc/button.c»:
  copyright : (c) 2006 Red-Bean Software
  license : 
$

Du må bruke propdel-delkommandoen for å fjerne egenskaper helt. Syntaksen er lik de andre egenskapskommandoene:

$ svn propdel license calc/button.c
Egenskapen «license» slettet fra «calc/button.c».
$ svn proplist --verbose calc/button.c
Egenskaper for 'calc/button.c':
  copyright : (c) 2006 Red-Bean Software
$

Husker du de uversjonerte revisjonsegenskapene? Du kan modifisere disse også ved hjelp av de samme delkommandoene for svn som vi nettopp beskrev. Bare legg til --revprop-valget på kommandolinja og spesifiser revisjonen for den egenskapen du vil forandre. Siden revisjoner er globale, trenger du ikke å spesifisere en målsti sammen med disse egenskapsrelaterte kommandoene så lenge du er i en arbeidskopi fra depotet som har revisjonsegenskapen du vil forandre. Ellers kan du oppgi URLen for en hvilken som helst sti i depotet det gjelder (inkludert depotets rotadresse). Du vil for eksempel erstatte loggmeldingen for en eksisterende revisjon.^[9] Hvis den nåværende katalogen er en del av en arbeidskopi fra depotet ditt, kan du ganske enkelt kjøre kommandoen svn propset uten å spesifisere en målsti:

$ svn propset svn:log '* button.c: Fjerna en kompilatoradvarsel.' -r11 --revprop
Egenskapen «svn:log» satt på depotrevisjon «11»
$

Men selv om du ikke har hentet ut en arbeidskopi fra depotet, kan du fortsatt forandre egenskapen ved å oppgi URLen til depotroten:

$ svn propset svn:log '* button.c: Fjerna en kompilatoradvarsel.' -r11 --revprop \
              http://svn.example.com/depot/prosjekt
Egenskapen «svn:log» satt på depotrevisjon «11»
$

Legg merke til at muligheten til å forandre disse uversjonerte egenskapene må settes spesielt av depotadministratoren (se “Påhakningsskript”). Siden egenskapene ikke er versjonerte, risikerer du å miste informasjon hvis du ikke er forsiktig når du redigerer. Depotadministratoren kan sette opp metoder for å beskytte mot datatap som dette, og standardoppsettet forbyr forandringer i revisjonsegenskaper.

Tips

Brukere bør, der det er mulig, bruke svn propedit istedenfor svn propset. Selv om sluttresultatet er identisk, vil førstnevnte la dem se den nåværende verdien av egenskapen som de er i ferd med å forandre, noe som hjelper dem å kontrollere at de faktisk gjør den endringen som de tror de gjør. Dette gjelder spesielt for modifisering av uversjonerte revisjonsegenskaper. I tillegg er det betraktelig enklere å redigere egenskaper som strekker seg over flere linjer i en tekstbehandler enn på kommandolinja.

Nå som du er kjent med alle svn-kommandoene som er relatert til egenskaper, la oss se hvordan forandringer i egenskaper påvirker den vanlige arbeidsflyten i Subversion. Som vi nevnte tidligere, er fil- og katalogegenskaper versjonerte, akkurat som innholdet i filene dine. Dette betyr at Subversion har de samme mulighetene for fletting – med dertil potensielle konflikter – av andres forandringer inn i dine egne.

Og i likhet med filinnhold, er forandringene dine i egenskapene lokale modifiseringer som kun blir gjort permanente når du legger dem inn i depotet med svn commit. Egenskapsforandringene kan lett omgjøres – kommandoen svn revert vil sette filene og katalogene dine tilbake til den uredigerte tilstanden – innhold, egenskaper, alt. Du kan også få interessant informasjon om tilstanden til fil- og katalogegenskapene ved å bruke kommandoene svn status og svn diff.

$ svn status calc/button.c
 M     calc/button.c
$ svn diff calc/button.c
Egenskapsforandringer på: calc/button.c
___________________________________________________________________
Navn: copyright
   + (c) 2006 Red-Bean Software

$

Legg merke til hvordan status-delkommandoen viser M i den andre kolonnen istedenfor den første. Det er fordi vi har forandret egenskapene på calc/button.c, men ikke forandret tekstinnholdet. Hadde vi forandret begge to, ville det også vært en M i den første kolonnen (se “svn status”).

% svn update calc
M  calc/Makefile.in
 C calc/button.c
Oppdatert til revisjon 143.
$

$ svn status calc
 C     calc/button.c
?      calc/button.c.prej
$ cat calc/button.c.prej
prop 'linecount': user set to '1256', but update set to '1301'.
$

Du har kanskje lagt merke til den smårare måten Subversion viser forskjeller i egenskaper på. Du kan fortsatt kjøre svn diff og omdirigere resultatet for å lage en gyldig patchfil. patch-programmet vil imidlertid ignorere patcher for egenskaper – alle data som det ikke forstår vil bli ignorert. Dette betyr dessverre at for å patche egenskaper med en fil laget av svn diff, må forandringer i egenskaper legges til for hånd.

Properties are a powerful feature of Subversion, acting as key components of many Subversion features discussed elsewhere in this and other chapters—textual diff and merge support, keyword substitution, newline translation, etc. But to get the full benefit of properties, they must be set on the right files and directories. Unfortunately, that can be a step easily forgotten in the routine of things, especially since failing to set a property doesn't usually result in an obvious error condition (at least compared to, say, failing to add a file to version control). To help your properties get applied to the places that need them, Subversion provides a couple of simple but useful features.

Whenever you introduce a file to version control using the svn add or svn import commands, Subversion tries to assist by setting some common file properties automatically. First, on operating systems whose filesystems support an execute permission bit, Subversion will automatically set the svn:executable property on newly added or imported files whose execute bit is enabled. (See “File Executability” for more about this property.) Secondly, it runs a very basic heuristic to determine if that file contains human-readable content. If not, Subversion will automatically set the svn:mime-type property on that file to application/octet-stream (the generic “this is a collection of bytes” MIME type). Of course, if Subversion guesses incorrectly, or if you wish to set the svn:mime-type property to something more precise—perhaps image/png or application/x-shockwave-flash—you can always remove or edit that property. (For more on Subversion's use of MIME types, see “File Content Type”.)

Subversion also provides, via its runtime configuration system (see “Konfigurasjonsområdet for bruk under kjøring”), a more flexible automatic property setting feature which allows you to create mappings of filename patterns to property names and values. Once again, these mappings affect adds and imports, and not only can override the default MIME type decision made by Subversion during those operations, but can also set additional Subversion or custom properties, too. For example, you might create a mapping that says that any time you add JPEG files—ones that match the pattern *.jpg—Subversion should automatically set the svn:mime-type property on those files to image/jpeg. Or perhaps any files that match *.cpp should have svn:eol-style set to native, and svn:keywords set to Id. Automatic property support is perhaps the handiest property related tool in the Subversion toolbox. See “Konfigurasjon” for more about configuring that support.

Subversion joins the ranks of the many applications which recognize and make use of Multipurpose Internet Mail Extensions (MIME) content types. Besides being a general-purpose storage location for a file's content type, the value of the svn:mime-type file property determines some behavioral characteristics of Subversion itself.

For example, one of the benefits that Subversion typically provides is contextual, line-based merging of changes received from the server during an update into your working file. But for files containing non-textual data, there is often no concept of a “line”. So, for versioned files whose svn:mime-type property is set to a non-textual MIME type (generally, something that doesn't begin with text/, though there are exceptions), Subversion does not attempt to perform contextual merges during updates. Instead, any time you have locally modified a binary working copy file that is also being updated, your file is renamed with a .orig extension, and then Subversion stores a new working copy file that contains the changes received during the update, but not your own local modifications, at the original filename. This behavior is really for the protection of the user against failed attempts at performing contextual merges on files that simply cannot be contextually merged.

Also, if the svn:mime-type property is set, then the Subversion Apache module will use its value to populate the Content-type: HTTP header when responding to GET requests. This gives your web browser a crucial clue about how to display a file when using it to peruse your Subversion repository's contents.

On many operating systems, the ability to execute a file as a command is governed by the presence of an execute permission bit. This bit usually defaults to being disabled, and must be explicitly enabled by the user for each file that needs it. But it would be a monumental hassle to have to remember exactly which files in freshly checked-out working copy were supposed to have their executable bits toggled on, and then to have to do that toggling. So, Subversion provides the svn:executable property as a way to specify that the executable bit for the file on which that property is set should be enabled, and Subversion honors that request when populating working copies with such files.

This property has no effect on filesystems that have no concept of an executable permission bit, such as FAT32 and NTFS. ^[11] Also, although it has no defined values, Subversion will force its value to * when setting this property. Finally, this property is valid only on files, not on directories.

Unless otherwise noted using a versioned file's svn:mime-type property, Subversion assumes the file contains human-readable data. Generally speaking, Subversion only uses this knowledge to determine if contextual difference reports for that file are possible. Otherwise, to Subversion, bytes are bytes.

This means that by default, Subversion doesn't pay any attention to the type of end-of-line (EOL) markers used in your files. Unfortunately, different operating systems have different conventions about which character sequences represent the end of a line of text in a file. For example, the usual line ending token used by software on the Windows platform is a pair of ASCII control characters—a carriage return (CR) followed by a line feed (LF). Unix software, however, just uses the LF character to denote the end of a line.

Not all of the various tools on these operating systems are prepared to understand files that contain line endings in a format that differs from the native line ending style of the operating system on which they are running. Common results are that Unix programs treat the CR character present in Windows files as a regular character (usually rendered as ^M), and that Windows programs combine all of the lines of a Unix file into one giant line because no carriage return-linefeed (or CRLF) character combination was found to denote the end of line.

This sensitivity to foreign EOL markers can become frustrating for folks who share a file across different operating systems. For example, consider a source code file, and developers that edit this file on both Windows and Unix systems. If all the developers always use tools which preserve the line ending style of the file, no problems occur.

But in practice, many common tools either fail to properly read a file with foreign EOL markers, or they convert the file's line endings to the native style when the file is saved. If the former is true for a developer, he has to use an external conversion utility (such as dos2unix or its companion, unix2dos) to prepare the file for editing. The latter case requires no extra preparation. But both cases result in a file that differs from the original quite literally on every line! Prior to committing his changes, the user has two choices. Either he can use a conversion utility to restore the modified file to the same line ending style that it was in before his edits were made. Or, he can simply commit the file—new EOL markers and all.

The result of scenarios like these include wasted time and unnecessary modifications to committed files. Wasted time is painful enough. But when commits change every line in a file, this complicates the job of determining which of those lines were changed in a non-trivial way. Where was that bug really fixed? On what line was a syntax error introduced?

The solution to this problem is the svn:eol-style property. When this property is set to a valid value, Subversion uses it to determine what special processing to perform on the file so that the file's line ending style isn't flip-flopping with every commit that comes from a different operating system. The valid values are:

In the Subversion repository, a lock is a piece of metadata which grants exclusive access to one user to change a file. This user is said to be the lock owner. Each lock also has a unique identifier, typically a long string of characters, known as the lock token. The repository manages locks, ultimately handling their creation, enforcement, and removal. If any commit transaction attempts to modify or delete a locked file (or delete one of the parent directories of the file), the repository will demand two pieces of information—that the client performing the commit be authenticated as the lock owner, and that the lock token has been provided as part of the commit process as a sort of proof that client knows which lock it is using.

To demonstrate lock creation, let's refer back to our example of multiple graphic designers working with on the same binary image files. Harry has decided to change a JPEG image. To prevent other people from committing changes to the file while he is modifying it (as well as alerting them that he is about to change it), he locks the file in the repository using the svn lock command.

$ svn lock banana.jpg --message "Editing file for tomorrow's release."
'banana.jpg' locked by user 'harry'.
$

There are a number of new things demonstrated in the previous example. First, notice that Harry passed the --message option to svn lock. Similar to svn commit, the svn lock command can take comments (either via --message (-m) or --file (-F)) to describe the reason for locking the file. Unlike svn commit, however, svn lock will not demand a message by launching your preferred text editor. Lock comments are optional, but still recommended to aid communication.

Secondly, the lock attempt succeeded. This means that the file wasn't already locked, and that Harry had the latest version of the file. If Harry's working copy of the file had been out-of-date, the repository would have rejected the request, forcing Harry to svn update and reattempt the locking command. The locking command would also have failed if the file already been locked by someone else.

As you can see, the svn lock command prints confirmation of the successful lock. At this point, the fact that the file is locked becomes apparent in the output of the svn status and svn info reporting subcommands.

$ svn status
     K banana.jpg

$ svn info banana.jpg
Path: banana.jpg
Name: banana.jpg
URL: http://svn.example.com/repos/project/banana.jpg
Repository UUID: edb2f264-5ef2-0310-a47a-87b0ce17a8ec
Revision: 2198
Node Kind: file
Schedule: normal
Last Changed Author: frank
Last Changed Rev: 1950
Last Changed Date: 2006-03-15 12:43:04 -0600 (Wed, 15 Mar 2006)
Text Last Updated: 2006-06-08 19:23:07 -0500 (Thu, 08 Jun 2006)
Properties Last Updated: 2006-06-08 19:23:07 -0500 (Thu, 08 Jun 2006)
Checksum: 3b110d3b10638f5d1f4fe0f436a5a2a5
Lock Token: opaquelocktoken:0c0f600b-88f9-0310-9e48-355b44d4a58e
Lock Owner: harry
Lock Created: 2006-06-14 17:20:31 -0500 (Wed, 14 Jun 2006)
Lock Comment (1 line):
Editing file for tomorrow's release.

$

That the svn info command, which does not contact the repository when run against working copy paths, can display the lock token reveals an important fact about lock tokens—that they are cached in the working copy. The presence of the lock token is critical. It gives the working copy authorization to make use of the lock later on. Also, the svn status command shows a K next to the file (short for locKed), indicating that the lock token is present.

Now that Harry has locked banana.jpg, Sally is unable to change or delete that file:

$ svn delete banana.jpg
D         banana.jpg
$ svn commit -m "Delete useless file."
Deleting       banana.jpg
svn: Commit failed (details follow):
svn: DELETE of
'/repos/project/!svn/wrk/64bad3a9-96f9-0310-818a-df4224ddc35d/banana.jpg':
423 Locked (http://svn.example.com)
$

But Harry, after touching up the banana's shade of yellow, is able to commit his changes to the file. That's because he authenticates as the lock owner, and also because his working copy holds the correct lock token:

$ svn status
M    K banana.jpg
$ svn commit -m "Make banana more yellow"
Sending        banana.jpg
Transmitting file data .
Committed revision 2201.
$ svn status
$

Notice that after the commit is finished, svn status shows that the lock token is no longer present in working copy. This is the standard behavior of svn commit—it searches the working copy (or list of targets, if you provide such a list) for local modifications, and sends all the lock tokens it encounters during this walk to the server as part of the commit transaction. After the commit completes successfully, all of the repository locks that were mentioned are released—even on files that weren't committed. This is meant to discourage users from being sloppy about locking, or from holding locks for too long. If Harry haphazardly locks thirty files in a directory named images because he's unsure of which files he needs to change, yet only only changes four of those file, when he runs svn commit images, the process will still release all thirty locks.

This behavior of automatically releasing locks can be overridden with the --no-unlock option to svn commit. This is best used for those times when you want to commit changes, but still plan to make more changes and thus need to retain existing locks. You can also make this your default behavior by setting the no-unlock runtime configuration option (see “Konfigurasjonsområdet for bruk under kjøring”).

Of course, locking a file doesn't oblige one to commit a change to it. The lock can be released at any time with a simple svn unlock command:

$ svn unlock banana.c
'banana.c' unlocked.

When a commit fails due to someone else's locks, it's fairly easy to learn about them. The easiest of these is svn status --show-updates:

$ svn status --show-updates
M              23   bar.c
M    O         32   raisin.jpg
       *       72   foo.h
Status against revision:     105
$

In this example, Sally can see not only that her copy of foo.h is out-of-date, but that one of the two modified files she plans to commit is locked in the repository. The O symbol stands for “Other”, meaning that a lock exists on the file, and was created by somebody else. If she were to attempt a commit, the lock on raisin.jpg would prevent it. Sally is left wondering who made the lock, when, and why. Once again, svn info has the answers:

$ svn info http://svn.example.com/repos/project/raisin.jpg
Path: raisin.jpg
Name: raisin.jpg
URL: http://svn.example.com/repos/project/raisin.jpg
Repository UUID: edb2f264-5ef2-0310-a47a-87b0ce17a8ec
Revision: 105
Node Kind: file
Last Changed Author: sally
Last Changed Rev: 32
Last Changed Date: 2006-01-25 12:43:04 -0600 (Sun, 25 Jan 2006)
Lock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Lock Owner: harry
Lock Created: 2006-02-16 13:29:18 -0500 (Thu, 16 Feb 2006)
Lock Comment (1 line):
Need to make a quick tweak to this image.
$

Just as svn info can be used to examine objects in the working copy, it can also be used to examine objects in the repository. If the main argument to svn info is a working copy path, then all of the working copy's cached information is displayed; any mention of a lock means that the working copy is holding a lock token (if a file is locked by another user or in another working copy, svn info on a working copy path will show no lock information at all). If the main argument to svn info is a URL, then the information reflects the latest version of an object in the repository, and any mention of a lock describes the current lock on the object.

So in this particular example, Sally can see that Harry locked the file on February 16th to “make a quick tweak”. It being June, she suspects that he probably forgot all about the lock. She might phone Harry to complain and ask him to release the lock. If he's unavailable, she might try to forcibly break the lock herself or ask an administrator to do so.

A repository lock isn't sacred—in Subversion's default configuration state, locks can be released not only by the person who created them, but by anyone at all. When somebody other than the original lock creator destroys a lock, we refer to this as breaking the lock.

From the administrator's chair, it's simple to break locks. The svnlook and svnadmin programs have the ability to display and remove locks directly from the repository. (For more information about these tools, see “En administrators verktøykasse”.)

$ svnadmin lslocks /usr/local/svn/repos
Path: /project2/images/banana.jpg
UUID Token: opaquelocktoken:c32b4d88-e8fb-2310-abb3-153ff1236923
Owner: frank
Created: 2006-06-15 13:29:18 -0500 (Thu, 15 Jun 2006)
Expires: 
Comment (1 line):
Still improving the yellow color.

Path: /project/raisin.jpg
UUID Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Owner: harry
Created: 2006-02-16 13:29:18 -0500 (Thu, 16 Feb 2006)
Expires: 
Comment (1 line):
Need to make a quick tweak to this image.

$ svnadmin rmlocks /usr/local/svn/repos /project/raisin.jpg
Removed lock on '/project/raisin.jpg'.
$

The more interesting option is allowing users to break each other's locks over the network. To do this, Sally simply needs to pass the --force to the unlock command:

$ svn status --show-updates
M              23   bar.c
M    O         32   raisin.jpg
       *       72   foo.h
Status against revision:     105
$ svn unlock raisin.jpg
svn: 'raisin.jpg' is not locked in this working copy
$ svn info raisin.jpg | grep URL
URL: http://svn.example.com/repos/project/raisin.jpg
$ svn unlock http://svn.example.com/repos/project/raisin.jpg
svn: Unlock request failed: 403 Forbidden (http://svn.example.com)
$ svn unlock --force http://svn.example.com/repos/project/raisin.jpg
'raisin.jpg' unlocked.
$

Now, Sally's initial attempt to unlock failed because she ran svn unlock directly on her working copy of the file, and no lock token was present. To remove the lock directly from the repository, she needs to pass a URL to svn unlock. Her first attempt to unlock the URL fails, because she can't authenticate as the lock owner (nor does she have the lock token). But when she passes --force, the authentication and authorization requirements are ignored, and the remote lock is broken.

Of course, simply breaking a lock may not be enough. In the running example, Sally may not only want to break Harry's long-forgotten lock, but re-lock the file for her own use. She can accomplish this by running svn unlock --force and then svn lock back-to-back, but there's a small chance that somebody else might lock the file between the two commands. The simpler thing to is steal the lock, which involves breaking and re-locking the file all in one atomic step. To do this, Sally passes the --force option to svn lock:

$ svn lock raisin.jpg
svn: Lock request failed: 423 Locked (http://svn.example.com)
$ svn lock --force raisin.jpg
'raisin.jpg' locked by user 'sally'.
$

In any case, whether the lock is broken or stolen, Harry may be in for a surprise. Harry's working copy still contains the original lock token, but that lock no longer exists. The lock token is said to be defunct. The lock represented by the lock-token has either been broken (no longer in the repository), or stolen (replaced with a different lock). Either way, Harry can see this by asking svn status to contact the repository:

$ svn status
     K raisin.jpg
$ svn status --show-updates
     B         32   raisin.jpg
$ svn update
  B  raisin.jpg
$ svn status
$

If the repository lock was broken, then svn status --show-updates displays a B (Broken) symbol next to the file. If a new lock exists in place of the old one, then a T (sTolen) symbol is shown. Finally, svn update notices any defunct lock tokens and removes them from the working copy.

We've seen how svn lock and svn unlock can be used to create, release, break, and steal locks. This satisfies the goal of serializing commit access to a file. But what about the larger problem of preventing wasted time?

For example, suppose Harry locks an image file and then begins editing it. Meanwhile, miles away, Sally wants to do the same thing. She doesn't think to run svn status --show-updates, so she has no idea that Harry has already locked the file. She spends hours editing the file, and when she tries to commit her change, she discovers that either the file is locked or that she's out-of-date. Regardless, her changes aren't mergeable with Harry's. One of these two people has to throw away their work, and a lot of time has been wasted.

Subversion's solution to this problem is to provide a mechanism to remind users that a file ought to be locked before the editing begins. The mechanism is a special property, svn:needs-lock. If that property is attached to a file (regardless of its value, which is irrelevant), then Subversion will try to use filesystem-level permissions to make the file read-only, unless, of course, the user has explicitly locked the file. When a lock-token is present (as a result of running svn lock), the file becomes read-write. When the lock is released, the file becomes read-only again.

The theory, then, is that if the image file has this property attached, then Sally would immediately notice something is strange when she opens the file for editing. Many applications alert users immediately when a read-only file is opened for editing. And nearly all applications would at least prevent her from saving changes to the file. This reminds her to lock the file before editing, whereby she discovers the pre-existing lock:

$ /usr/local/bin/gimp raisin.jpg
gimp: error: file is read-only!
$ ls -l raisin.jpg
-r--r--r--   1 sally   sally   215589 Jun  8 19:23 raisin.jpg
$ svn lock raisin.jpg
svn: Lock request failed: 423 Locked (http://svn.example.com)
$ svn info http://svn.example.com/repos/project/raisin.jpg | grep Lock
Lock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Lock Owner: harry
Lock Created: 2006-06-08 07:29:18 -0500 (Thu, 08 June 2006)
Lock Comment (1 line):
Making some tweaks.  Locking for the next two hours.
$

	Tips
	Users and administrators alike are encouraged to attach the svn:needs-lock property to any file which cannot be contextually merged. This is the primary technique for encouraging good locking habits and preventing wasted effort.

Note that this property is a communication tool which works independently from the locking system. In other words, any file can be locked, whether or not this property is present. And conversely, the presence of this property doesn't make the repository require a lock when committing.

Unfortunately, the system isn't flawless. It's possible that even when a file has the property, the read-only reminder won't always work. Sometimes applications misbehave and “hijack” the read-only file, silently allowing users to edit and save the file anyway. There's not much that Subversion can do in this situation—at the end of the day, there's simply no substitution for good interpersonal communication. ^[16]

Subversionklienten bruker mesteparten av tida til å behandle arbeidskopier. Men når den trenger informasjon fra et depot foretar den en nettverksforespørsel og serveren kommer med et passende svar. Detaljene i nettverksprotokollen er skjult for brukeren; klienten prøver å aksessere en URL, og alt etter hvilket URL-skjema som brukes blir en passende protokoll brukt for å aksessere serveren (se Depot-URLer). Brukere kan kjøre svn --version for å se hvilke URL-skjema og protokoller klienten kan bruke.

Når serveren mottar en klientforespørsel, forlanger den vanligvis at klienten identifiserer seg. Den utsteder en autentiseringsforespørsel til klienten, og klienten svarer ved å legitimere seg ovenfor serveren. Når autentiseringen er komplett, svarer serveren med den originale informasjonen klienten spurte etter. Legg merke til at dette systemet er forskjellig fra systemer som CVS, hvor klienten på forhånd oppgir legitimasjon (“logger inn”) til serveren før noen forespørsel etter informasjon blir gjort. I Subversion “henter” serveren legitimasjonen ved å kontrollere klienten på det nødvendige tidspunktet i stedet for at klienten uoppfordret “leverer” den. Dette gjør visse operasjoner mer elegant. For eksempel, hvis en server er konfigurert til å la alle i hele verden få lese depotet, vil serveren aldri be om autentisering når klienten prøver en svn checkout.

Hvis klientens nettverksforespørsel skriver nye data til depotet (for eksempel svn commit), vil et nytt revisjonstre bli opprettet. Hvis klientens forespøsel ble autentisert, blir brukernavnet til den autentiserte brukeren lagret i svn:author-egenskapen i den nye revisjonen (se “Uversjonerte egenskaper”). Hvis klienten ikke ble autentisert (med andre ord, serveren spurte ikke etter legitimasjon), er revisjonens svn:author-egenskap tom.^[19]

Mange servere er satt opp til å forlange autentisering for hver eneste forespørsel. Dette kan bli et stort irritasjonsmoment for brukerne, som blir tvunget til å skrive passordet om og om igjen.

Heldigvis har Subversion en løsning på dette: Et innebygget system for å lagre legitimasjonen på disk. Normalt sett, når kommandolinjeklienten klarer å svare riktig på en autentiseringsforespørsel fra en server, lagres denne legitimasjonsinformasjonen i brukerens private konfigurasjonsområde – i ~/.subversion/auth/ på Unix-lignende systemer eller %APPDATA%/Subversion/auth/ i Windows. (Konfigurasjonsområdet er dekket mer inngående i “Konfigurasjonsområdet for bruk under kjøring”.) Data fra vellykkede autentiseringer lagres på disken, der nøkkelen er en kombinasjon av servernavn, port og området der autentiseringen gjelder.

Når klienten må gjennom en autentiseringsprosess, ser den først etter passende legitimasjonsdata i brukerens lager på disken. Hvis dette ikke finnes, eller de lagrede legitimasjonsdataene ikke er tilstrekkelig for å fullføre autentiseringen, spør klienten ganske enkelt brukeren etter informasjonen.

Sikkerhetsbevisste folk tenker nok med seg selv: “Lagre passord på disken? Det er forferdelig! Sånt skal aldri gjøres!” Men ta det med ro, det er ikke så farlig som det høres ut.

For å forhindre lagring for en enkelt kommando, spesifiser valget --no-auth-cache:

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

# Passordet ble ikke lagret, så ved neste innlegging blir vi spurt på 
# nytt.

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

Eller, hvis du vil slå av lagring av legitimasjonen permanent, kan du redigere config-fila (plassert ved siden av auth/-katalogen). Ved å sette store-auth-creds til no vil ingen legitimasjon bli lagret på disken i det hele tatt.

[auth]
store-auth-creds = no

Noen ganger vil brukere ønske å fjerne spesifikke legitimasjonsdata fra disklageret. For å gjøre dette, må du gå inn i auth/-området og manuelt slette den aktuelle fila. Legitimasjonen er lagret i individuelle filer, og hvis du ser på hver fil, vil du se nøkler og verdier. svn:realmstring-nøkkelen viser hvilket serverområde fila er assosiert med:

$ 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

Når du har funnet den riktige fila, er det bare å slette den.

Et siste ord om oppførselen under klientautentisering, en liten forklaring angående --username og --password er på sin plass. Mange delkommandoer for klienten godtar disse valgene, men det er viktig å forstå at bruken av disse valgene sender ikke brukerdata til serveren. Som tidligere nevnt, “henter” serveren brukerdata fra klienten når det er nødvendig; klienten kan ikke “levere” dataene når den vil. Hvis et brukernavn og/eller passord blir spesifisert som valg, vil de bare bli gitt til serveren hvis serveren spør etter dem.^[20] Vanligvis blir disse valgene brukt når:

Her er en avsluttende oversikt som beskriver hvordan en Subversionklient oppfører seg når den mottar en autentiseringsforespørsel:

Hvis klienten klarer å legitimere seg ved hjelp av noen av metodene nevnt ovenfor, vil den prøve å lagre brukerdataene på disken (unntatt hvis brukeren har slått av denne oppførselen, som tidligere nevnt).

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/
Sjekket ut revisjon 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 "Lager en privat gren av /calc/trunk."
Legger til         branches/my-calc-branch
La inn revisjon 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."

La inn revisjon 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.^[21] 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
Sjekket ut revisjon 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 ei fils historie”, som skjer med integer.c.

Figur 4.4. Forgreningen av ei 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 | bruker | 2002-11-07 15:27:56 -0600 (tor, 07 nov 2002) | 2 lines
Endrede filstier:
   M /calc/branches/my-calc-branch/integer.c

* integer.c:  frozzled the wazjub.

------------------------------------------------------------------------
r341 | bruker | 2002-11-03 15:27:56 -0600 (tor, 07 nov 2002) | 2 lines
Endrede filstier:
   A /calc/branches/my-calc-branch (fra /calc/trunk:340)

Lager en privat gren av /calc/trunk.

------------------------------------------------------------------------
r303 | sally | 2002-10-29 21:14:35 -0600 (tir, 29 okt 2002) | 2 lines
Endrede filstier:
   M /calc/trunk/integer.c

* integer.c:  Forandret en docstring.

------------------------------------------------------------------------
r98 | sally | 2002-02-22 15:35:29 -0600 (fre, 22 feb 2002) | 2 lines
Endrede filstier:
   M /calc/trunk/integer.c

* integer.c:  Legger til denne fila i prosjektet.

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

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 fila:

$ pwd
/home/sally/calc

$ svn log --verbose integer.c
------------------------------------------------------------------------
r344 | sally | 2002-11-07 15:27:56 -0600 (tor, 07 nov 2002) | 2 lines
Endrede filstier:
   M /calc/trunk/integer.c

* integer.c:  Ordnet en dunge med skrivefeil.

------------------------------------------------------------------------
r303 | sally | 2002-10-29 21:14:35 -0600 (tir, 29 okt 2002) | 2 lines
Endrede filstier:
   M /calc/trunk/integer.c

* integer.c:  Forandret en docstring.

------------------------------------------------------------------------
r98 | sally | 2002-02-22 15:35:29 -0600 (fre, 22 feb 2002) | 2 lines
Endrede filstier:
   M /calc/trunk/integer.c

* integer.c:  Legger til denne fila i prosjektet.

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

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 fila. 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 fila har uten tvil de samme skrivefeilene. Det er sannsynlig at dine fremtidige forandringer i denne fila 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 2, Grunnleggende bruk). 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	(revisjon 343)
+++ integer.c	(revisjon 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 2, Grunnleggende bruk), 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 boka 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
Sender fildata .
La inn revisjon 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, Subversion Complete Reference 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 ei fil, og denne fila (eller ei 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.

Tips

En fin måte å finne revisjonen en gren ble opprettet i (“basen” av forgreningen) er å bruke valget --stop-on-copy til svn log. Delkommandoen svn log vil normalt vise hver eneste forandring gjort på grenen, inkludert å gå forbi kopieringen som opprettet grenen. Så vanligvis vil du også se historien fra trunk. --stop-on-copy-valget vil stoppe loggutlistingen med en gang svn log finner ut at målet ble kopiert eller skiftet navn. Så hvis vi går videre i eksempelet, $ svn log --verbose --stop-on-copy \ http://svn.example.com/repos/calc/branches/my-calc-branch … ------------------------------------------------------------------------ r341 | bruker | 2002-11-03 15:27:56 -0600 (tor, 07 nov 2002) | 2 lines Endrede filstier: A /calc/branches/my-calc-branch (fra /calc/trunk:340) $ Som forventet er den siste revisjonen skrevet ut av denne kommandoen den revisjonen der my-calc-branch ble opprettet ved kopiering.

Her er den siste fletteprosedyren, og deretter:

$ cd calc/trunk
$ svn update
På revisjon 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."
Sender        integer.c
Sender        button.c
Sender        Makefile
Sender fildata ...
La inn revisjon 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 (søn, 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
På revisjon 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."
Sender        integer.c
Sender        button.c
Sender        Makefile
Sender fildata ...
La inn revisjon 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."
Sender        integer.c
Sender fildata .
La inn revisjon 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, til arbeidskopien din. I vårt tilfelle med å omgjøre en forandring ber vi 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 der 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.^[23]

Det som er fint med versjonskontrollsystemer er at informasjon aldri går tapt. Selv om du sletter ei fil eller en 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 fila 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 fila eller katalogen din kan bli definert som et spesifikt koordinatpar.

Subversion har ingen Attic-katalog som CVS har,^[24] 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 fila 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 (fre, 26 des 2003) | 3 lines
Endrede filstier:
   D /calc/trunk/real.c
   M /calc/trunk/integer.c

La inn Fast Fourier transform-funksjoner i integer.c .
Slettet real.c fordi koden nå ligger i 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 fila ble slettet i revisjon 808. Derfor er den siste versjonen av fila 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. Fila vil bli klargjort for tillegging, og etter en innlegging med svn commit vil fila eksistere i HEAD igjen.

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ålrettet 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 "Hentet tilbake real.c from revisjon 807, /calc/trunk/real.c ."
Legger til         real.c
Sender fildata .
La inn revisjon 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 fila gå tilbake forbi gjenoppstandelsen av fila 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 fila.

Selv om eksempelet vårt viser at vi henter tilbake ei 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 blant erfarne brukere ofte er ansett som de beste metodene. Disse prosessene er ikke spesifikke for Subversion; de kan brukes med ethvert versjonskontrollsystem. Men det kan hjelpe å se dem beskrevet i Subversionterminologi.

$ cd trunk-i-arbeidskopien

$ svn update
På revisjon 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  nykatalog
A  nykatalog/nyfil
…

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/versjon-1.0 \
      -m "Merker 1.0-versjonen av «calc»-prosjektet."

La inn revisjon 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 versjon-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 på et merke og en gren. Begge er bare vanlige kataloger som er opprettet ved kopiering. Akkurat som med grener er den eneste grunnen til at en kopiert katalog er et “merke” fordi mennesker har bestemt seg for å behandle den på denne måten: Så lenge ingen legger inn forandringer i katalogen, forblir den for alltid et øyeblikksbilde. Hvis noen begynner å legge inn forandringer i 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 for 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, Serverkonfigurasjon). Den paranoide ruten er imidlertid vanligvis ikke nødvendig. Hvis en bruker legger inn en forandring i 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 skal ha en spesiell funksjonalitet sammen med 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, Subversion Complete Reference), inkludert muligheten til å kopiere et tre av en arbeidskopi til depotet:

$ ls
min-arbeidskopi/

$ svn copy min-arbeidskopi 
http://svn.example.com/repos/calc/tags/mittmerke

La inn revisjon 352.

Nå er det en ny katalog i depotet, /calc/tags/mittmerke, 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 patchfila (som ikke vil fange opp treforandringer eller forandringer i symbolske linker eller egenskaper), 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 å lagre “hovedlinjen” av utviklingen, 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 oppsettene. 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 et utseende til et annet er bare snakk om å utføre en serie flyttinger på serveren; hvis du ikke liker måten ting er organisert på i depotet, er det bare å ommøblere på katalogene.

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 hun bli fortalt at arbeidskopien hennes 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. Tenk deg for eksempel 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/min-calc-gren \
             -m "Fjerner avlegs gren i calc-prosjektet."

La inn revisjon 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/min-calc-gren \
                  http://svn.example.com/repos/calc/branches/min-calc-gren

La inn revisjon 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 deg 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/stabil-1.0 \
         -m "Lager stabil gren av calc-prosjektet."

La inn revisjon 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 kun feilrettinger skal legges inn i /calc/branches/stabil-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.

Dette er måten vedlikehold av leverandørgrener vanligvis fungerer på. Du lager en katalog på toppnivå (som for eksempel /vendor) for å lagre leverandørgrenene. Deretter importerer du tredjepartskoden inn i en underkatalog i denne toppkatalogen. Så kopierer du denne underkatalogen inn på grenen der hovedutviklingen foregår (for eksempel /trunk på den riktige plasseringen. Du gjør alltid dine lokale forandringer på grenen der hovedutviklingen foregår. For hver ny utgivelse av koden du følger med på, legger du den inn på leverandørgrenen og fletter forandringene inn i /trunk og ordner eventuelle konflikter som måtte oppstå mellom dine lokale forandringer og de offisielle forandringene.

Kanskje vil et eksempel hjelpe på å klarne opp i fremgangsmåten. Vi bruker en situasjon der utviklingsteamet lager et regneprogram som lenker mot et tredjeparts bibliotek for kompleks aritmetikk, libcomplex. Vi starter med den innledende opprettelsen av leverandørgrenen og den første importen av leverandørutgivelsen. Vi kaller leverandørgrenen libcomplex, og leverandørutgivelsene går i en underkatalog i leverandørgrenen kalt current. Og siden svn import oppretter alle de mellomliggende foreldrekataloger som vi trenger, kan vi faktisk gjøre begge disse stegene med en enkelt kommando.

$ svn import /sti/til/libcomplex-1.0 \
             http://svn.example.com/repos/vendor/libcomplex/current \
             -m 'Importerer innledende 1.0-versjon'
…

Vi har nå den nåværende versjonen av libcomplex-kildekoden i /vendor/libcomplex/current. Nå merker vi denne versjonen (se “Merker (“tags”)” og deretter kopierer den inn på hovedutviklingsgrenen. Kopien vår vil opprette en ny katalog kalt libcomplex i den eksisterende prosjektkatalogen calc. Det er i denne kopien av leverandørdataene vi vil gjøre forandringene.

$ svn copy http://svn.example.com/repos/vendor/libcomplex/current  \
           http://svn.example.com/repos/vendor/libcomplex/1.0      \
           -m 'Merker libcomplex-1.0'
…
$ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0  \
           http://svn.example.com/repos/calc/libcomplex        \
           -m 'Legger libcomplex-1.0 inn på hovedgrenen'
…

Vi henter ut prosjektets hovedgren – som nå inneholder en kopi av den første leverandørutgivelsen – og vi setter i gang med å tilpasse libcomplex-koden. Før vi vet ordet av det, er den modifiserte versjonen av libcomplex fullstendig integrert i kalkulatorprogrammet.^[26]

Noen uker senere slipper utviklerne av libcomplex en ny versjon av biblioteket – versjon 1.1 – som inneholder trivelig funksjonalitet som vi har lyst på. Vi vil oppgradere til denne nye versjonen, men uten å miste forandringene vi gjorde i den eksisterende versjonen. Det vi egentlig vil gjøre, er å erstatte den nåværende utviklingsversjonen med en kopi av libcomplex 1.1 og deretter legge inn forandringene våre i den nye versjonen. Men vi gjør det faktisk den andre veien, legger inn forandringene i libcomplex mellom versjon 1.0 og 1.1 i den modifiserte kopien av den.

For å gjennomføre denne oppgraderingen, henter vi ut en kopi av leverandørgrenen og erstatter koden i current-katalogen med den nye koden for libcomplex 1.1. Vi kopierer bokstavelig talt nye filer på toppen av eksisterende filer, kanskje ved å pakke ut .tar.gz-fila oppå de eksisterende filene og katalogene. Meningen med dette er å få current-katalogen til å inneholde kun koden fra libcomplex 1.1, og å forsikre seg om at all denne koden er under versjonskontroll. Og en annen ting var at vi ville at dette skulle skje uten å forstyrre versjonskontrollhistorien alt for mye.

Etter å ha erstattet 1.0-koden med 1.1, vil svn status vise filer med lokale forandringer sammen med filer som kanskje er uversjonert eller mangler. Hvis vi gjorde det vi skulle, er de uversjonerte filene bare de nye filene introdusert i 1.1-versjonen av libcomplex – vi kjører svn add på disse for å få dem under versjonskontroll. De manglende filene er filer som var i 1.0, men ikke i 1.1, og på disse stiene kjører vi svn delete. Helt til slutt, når current-arbeidskopien kun inneholder koden for libcomplex 1.1, legger vi inn forandringene vi gjorde for å få den til å se ut som den gjør.

Nå inneholder current-grenen den nye leverandørversjonen. Vi merker den nye versjonen (på den samme måten vi tidligere merket 1.0-versjonen) og fletter deretter forandringene mellom merket for den forrige versjonen og den nye gjeldende versjonen inn i hovedutviklingsgrenen.

$ cd arbeidskopier/calc
$ svn merge http://svn.example.com/repos/vendor/libcomplex/1.0      \
            http://svn.example.com/repos/vendor/libcomplex/current  \
            libcomplex
… # Rydd opp i alle konfliktene mellom deres og våre forandringer
$ svn commit -m 'merging libcomplex-1.1 into the main branch'
…

I enkle sitasjoner vil den nye versjonen av tredjepartsdataene se ut som, fra et fil og katalog-syn, akkurat om den forrige versjonen. Ingen av filene i libcomplex vil være slettet, ha fått nytt navn eller blitt flyttet til andre plasseringer – den nye versionen vil bare inneholde tekstmessige forandringer i forhold til den forrige. I en perfekt verden ville våre forandringer legge seg inn i den nye versjonen uten antydning til komplikasjoner eller konflikter.

Men det er ikke alltid så enkelt, og faktisk er det ganske vanlig for kildekodefiler å bli flyttet rundt mellom programutgivelser. Dette kompliserer prosessen som går ut på å forsikre seg om at våre forandringer fortsatt er gyldige for den nye versjonen av koden, noe som kan ende med den situasjonen at vi manuelt må gjenopprette våre forandringer i den nye versjonen. Når Subversion vet om historien til en gitt kildefil – inkludert alle dens tidligere plasseringer – er prosessen med å flette inn den nye versjonen av biblioteket ganske enkel. Men vi er ansvarlig for å fortelle Subversion hvordan kildekodelayouten forandret seg fra leverandørversjon til leverandørversjon.

Vendor drops that contain more than a few deletes, additions and moves complicate the process of upgrading to each successive version of the third-party data. So Subversion supplies the svn_load_dirs.pl script to assist with this process. This script automates the importing steps we mentioned in the general vendor branch management procedure to make sure that mistakes are minimized. You will still be responsible for using the merge commands to merge the new versions of the third-party data into your main development branch, but svn_load_dirs.pl can help you more quickly and easily arrive at that stage.

In short, svn_load_dirs.pl is an enhancement to svn import that has several important characteristics:

svn_load_dirs.pl takes three mandatory arguments. The first argument is the URL to the base Subversion directory to work in. This argument is followed by the URL—relative to the first argument—into which the current vendor drop will be imported. Finally, the third argument is the local directory to import. Using our previous example, a typical run of svn_load_dirs.pl might look like:

$ svn_load_dirs.pl http://svn.example.com/repos/vendor/libcomplex \
                   current                                        \
                   /path/to/libcomplex-1.1
…

You can indicate that you'd like svn_load_dirs.pl to tag the new vendor drop by passing the -t command-line option and specifying a tag name. This tag is another URL relative to the first program argument.

$ svn_load_dirs.pl -t libcomplex-1.1                              \
                   http://svn.example.com/repos/vendor/libcomplex \
                   current                                        \
                   /path/to/libcomplex-1.1
…

When you run svn_load_dirs.pl, it examines the contents of your existing “current” vendor drop, and compares them with the proposed new vendor drop. In the trivial case, there will be no files that are in one version and not the other, and the script will perform the new import without incident. If, however, there are discrepancies in the file layouts between versions, svn_load_dirs.pl will prompt you for how you would like to resolve those differences. For example, you will have the opportunity to tell the script that you know that the file math.c in version 1.0 of libcomplex was renamed to arithmetic.c in libcomplex 1.1. Any discrepancies not explained by moves are treated as regular additions and deletions.

The script also accepts a separate configuration file for setting properties on files and directories matching a regular expression that are added to the repository. This configuration file is specified to svn_load_dirs.pl using the -p command-line option. Each line of the configuration file is a whitespace-delimited set of two or four values: a Perl-style regular expression to match the added path against, a control keyword (either break or cont), and then optionally a property name and value.

\.png$              break   svn:mime-type   image/png
\.jpe?g$            break   svn:mime-type   image/jpeg
\.m3u$              cont    svn:mime-type   audio/x-mpegurl
\.m3u$              break   svn:eol-style   LF
.*                  break   svn:eol-style   native

For each added path, the configured property changes whose regular expression matches the path are applied in order, unless the control specification is break (which means that no more property changes should be applied to that path). If the control specification is cont—an abbreviation for continue—then matching will continue with the next line of the configuration file.

Any whitespace in the regular expression, property name, or property value must be surrounded by either single or double quote characters. You can escape quote characters that are not used for wrapping whitespace by preceding them with a backslash (\) character. The backslash escapes only quotes when parsing the configuration file, so do not protect any other characters beyond what is necessary for the regular expression.

Konseptmessig sagt er et Subversiondepot en sekvens av trær. Hvert tre er et øyeblikksbilde av hvordan filene og katalogene så ut på et spesielt tidspunkt. Disse øyeblikksbildene er opprettet som et resultat av klientoperasjoner og blir kalt revisjoner.

Hver revisjon begynner livet som et transaksjonstre. Når du gjør en innlegging, bygger en klient en Subversiontransaksjon som avspeiler deres lokale forandringer (pluss eventuelle forandringer som er blitt lagt inn i tillegg til depotet siden begynnelsen av innleggingsprosessen), og instruerer deretter depotet om å lagre dette treet som det neste øyeblikksbildet i sekvensen. Hvis innleggingen lykkes, blir transaksjonen innlemmet i et nytt revisjonstre, og blir tildelt et nytt revisjonsnummer. Hvis innleggingen av en eller annen grunn ikke lykkes, blir transaksjonen ødelagt og klienten informeres om feilen.

Oppdateringer fungerer på en lignende måte. Klienten bygger et midlertidig transaksjonstre som avspeiler tilstanden til arbeidskopien. Depotet sammenligner deretter dette transaksjonstreet med revisjonstreet i den forespurte revisjonen (vanligvis det nyeste, eller “yngste” treet), og sender tilbake informasjon som forteller klienten om hvilke forandringer som er nødvendig for å forandre deres arbeidskopi til et replikat av det aktuelle revisjonstreet. Etter at oppdateringen er fullført, blir den midlertidige transaksjonen slettet.

Bruken av transaksjonstrær er den eneste måten å gjøre permanente forandringer til et depots versjonskontrollerte filsystem. Det er imidlertid viktig å forstå at livløpet til en transaksjon er komplett fleksible. I tilfellet med oppdateringer er transaksjoner midlertidige trær som blir øyeblikkelig ødelagt. I tilfellet med innlegginger blir transaksjoner transformert inn i permanente revisjoner (eller fjernet hvis innleggingen feiler). I tilfelle en generell feil eller programfeil oppstår, er det mulig at en transaksjon kan bli liggende igjen i depotet (uten å påvirke noe som helst, men tar opp diskplass).

I teorien vil kanskje hele arbeidsflytapplikasjoner en gang gi mer nøyaktig kontroll med levetiden til en transaksjon. Det er mulig å tenke seg et system som ved hver transaksjon beregnet på å bli en revisjon blir satt på venting etter at klienten er ferdig med å beskrive sine forandringer til depotet. Dette ville muliggjøre at hver ny innlegging kan bli sett over av noen andre, kanskje en manager eller ledende utvikler, som kan velge å forfremme transaksjonen til en revisjon eller avbryte den.

Transaksjoner og revisjoner i Subversiondepotet kan ha vedlagte egenskaper. Disse egenskapene er generiske “nøkkel-til-verdi”-mappinger, og blir vanligvis brukt til å lagre informasjon om treet som de er vedlagt. Navnene og verdiene til disse egenskapene er lagret i depotets filsystem, sammen med resten av dataene for treet.

Revisjons- og transaksjonsegenskaper er nyttige for å assosiere informasjon sammen med et tre som ikke er spesifikt relatert til filene og katalogene i dette treet ― den typen informasjon som ikke er behandlet av arbeidskopier for klienten. For eksempel, når en ny innleggingstransaksjon er opprettet i depotet, legger Subversion en egenskap til denne transaksjonen kalt svn:date – et tidsmerke som representerer tidspunktet transaksjonen ble opprettet. Når innleggingsprosessen er fullført, og transaksjonen blir forfremmet til en permanent revisjon, har treet også fått en egenskap for å lagre brukernavnet til revisjonens forfatter (svn:author) og en egenskap for å lagre loggmeldingen som hører til denne revisjonen svn:log.

Revisjons- og transaksjonsegenskaper er uversjonerte egenskaper – når de blir modifisert blir den foregående verdien permanent forkastet. Selv om revisjonstrær er uforanderlige, gjelder ikke dette egenskapene som er vedlagt disse trærne. Du kan legge til, fjerne, og modifisere revisjonsegenskaper til enhver tid i fremtiden. Hvis du legger inn en ny revisjon og senere finner ut at du la inn feil informasjon eller skrivefeil i loggmeldingen, kan du enkelt forandre verdien i svn:log-egenskapen med en ny, rettet loggmelding.

I Subversion 1.1 er det to valg for å lagre data i et Subversiondepot. En depottype lagrer alt i en Berkeley DB-database; den andre typen lagrer data som ordinære “flate filer” i et tilpasset format. Fordi Subversionutviklere ofte referer til et depot som “det (versjonerte) filsystemet”, har de lagt seg til vanen med å refere til den sistnevnte typen depot som FSFS^[28] – en versjonert filsystemimplementasjon som bruker det vanlige filsystemet til operativsystemet for å lagre data.

Når et depot er opprettet, må administratoren bestemme om Berkeley DB eller FSFS skal brukes. Det er fordeler og ulemper med begge to, som vi vil gå gjennom ganske snart. Ingen av de bakenforliggende depotene er mer “offisielle” enn andre, og programmer som aksesserer depotet er beskyttet fra denne implementasjonsdetaljen. Programmer har ingen formening om hvordan depotet lagrer data; de ser bare revisjons- og transaksjonstrær gjennom depotgrensesnittet.

Tabell 5.1, “Sammenligning av datalagring i depoter” inneholder en tabell som gir en oversikt over forskjellene mellom depoter av typen Berkeley DB og FSFS. De neste seksjonene går inn i detalj.

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

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

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

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

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

Tips

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

Det er lagt inn ni påhakninger i Subversiondepotet:

Advarsel

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

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

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

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

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

Subversion har en håndfull programmer som er nyttige til å opprette, inspisere, modifisere og reparere depotet ditt. La oss se litt nærmere på hvert av disse verktøyene. Etterpå vil vi gå raskt over noen av de programmene som er inkludert i Berkeley DB-distribusjonen som tilbyr funksjonalitet spesifikk til databasedelen i depotet som ikke Subversions egne verktøy tar seg av.

$ svnlook 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
La til det vanlige
greske treet.

$ 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

Siden Subversion lagrer alt i et skjult databasesystem, er det å prøve på manuelle forandringer ikke spesielt lurt, for ikke å si vanskelig. Og når dataene er lagret i depotet, har ikke Subversion noen enkel måte å fjerne disse dataene.^[29] Men det er ikke til å komme forbi at det er noen ganger du vil manipulere historien til depotet ditt. Det kan være at du vil fjerne alle spor etter ei fil som ble lagt til ved en ulykke (og som av en eller annen grunn ikke skal være der). Eller du har kanskje flere prosjekter som deler et enkelt depot, og du bestemmer deg for å dele dem opp i sine egne depoter. For å utføre oppgaver som dette, trenger administratorer en mer håndterlig og formbar representasjon av dataene i deres egne depot – dumpformatet for Subversiondepot.

Dumpformatet for Subversiondepot er en representasjon av forandringene som du har gjort i dine versjonerte data over tid, i et menneskelig lesbart format. Du bruker kommandoen svnadmin dump for å generere dumpdataene og svnadmin load for å legge disse dataene inn i et nytt depot (se “Flytte et depot”). Den fine tingen med det menneskelesbare dumpformatet er at du kan inspisere og modifisere det hvis du er forsiktig. Selvfølgelig, bakdelen er at hvis du har to år med depotaktivitet pakket inn i en stor dumpfil, vil det ta deg lang, lang tid å manuelt inspisere og modifisere den.

Selv om det ikke vil være det vanligste verktøyet til bruk for depotadministratoren, gir svndumpfilter en veldig spesiell type nyttig funksjonalitet – muligheten til å raskt og enkelt modifisere disse dumpdataene ved å fungere som et stibasert filter. Du gir ganske enkelt programmet en liste over stier som du vil beholde, eller en liste med stier som du vil fjerne, og sender deretter dumpdataene fra depotet via et rør gjennom dette filteret. Resultatet er en modifisert strøm av dumpdata som kun inneholder de versjonerte stiene som du (eksplisitt eller implisitt) ba om.

Syntaksen for svndumpfilter er som følger:

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

Available subcommands:
   exclude
   include
   help (?, h)

Her er det bare to interessante delkommandoer. De gir deg valget mellom eksplisitt eller implisitt inkludering av stier i strømmen:

exclude

Filtrer bort et sett med stier fra dumpdatastrømmen.

include

Tillat bare de angitte stiene å slippe gjennom dumpdatastrømmen.

La oss se på et realistisk eksempel på hvordan du vil bruke dette programmet. Vi diskuterer en annen plass (se “Velge en depot-layout”) prosessen med å bestemme hvordan dataene i depotene dine skal legges opp – om du vil bruke ett depot for hvert prosjekt eller kombinere dem, hvordan du arrangerer ting innenfor depotet og så videre. Men noen ganger etter at nye revisjoner begynner å komme inn, tenker du på nytt over layouten og vil gjøre noen forandringer. En vanlig forandring er å bestemme seg for å flytte flere prosjekter som deler et enkelt depot inn i separate depot for hvert prosjekt.

Vårt hypotetiske depot inneholder tre prosjekter: calc, calendar og spreadsheet. De har levd ved siden av hverandre som følger:

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

For å få disse tre prosjektene inn i deres egne depot, dumper vi først hele depotet:

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

Så kjører vi denne dumpfila gjennom filteret og for hver gang inkluderer vi bare en av katalogene på toppnivå, noe som resulterer i tre nye dumpfiler:

$ cat depot-dumpfil | svndumpfilter include calc > calc-dumpfil
…
$ cat depot-dumpfil | svndumpfilter include calendar > cal-dumpfil
…
$ cat depot-dumpfil | svndumpfilter include spreadsheet > ss-dumpfil
…
$

På dette punktet må du ta en avgjørelse. Hver av dumpfilene fine vil lage et gyldig depot, men vil gjenskape stiene nøyaktig som de var i det opprinnelige depotet. Dette betyr at selv om du vil ha et depot kun for calc-prosjektet, vil dette depotet fortsatt ha en toppkatalog kalt calc. Hvis du vil at katalogene trunk, tags og branches skal være i roten av depotet, vil du kanskje ønske å redigere dumpfilene og forandre Node-path og Node-copyfrom-path i headerne så de ikke lengre inneholder denne calc/-komponenten i stien. I tillegg ønsker du å fjerne seksjonen i dumpdataene som oppretter calc-katalogen. Det vil se ut omtrent som dette:

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

	Advarsel
	Hvis du planlegger å redigere dumpfila manuelt for å fjerne en toppkatalog, vær sikker på at tekstbehandleren din ikke er satt til å automatisk konvertere linjeslutt til det lokale formatet (det vil si \r\n til \n). Dette vil føre til at innholdet ikke vil samsvare med metadataene og dumpfila vil dermed bli ubrukelig.

Alt som gjenstår nå er å opprette dine tre nye depot og laste hver dumpfil inn i det riktige depotet:

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

Begge delkommandoene til svndumpfilter godtar valg for å bestemme hva de skal gjøre med “tomme” revisjoner. Hvis en gitt revisjon bare inneholdt forandringer i stier som ble filtrert bort kan denne revisjonen som nå er tom bli betraktet som uinteressant eller til og med uønsket. Så for å gi brukeren kontroll over hva som skal gjøres med disse revisjonene, har svndumpfilter disse kommandolinjevalgene:

--drop-empty-revs

Ikke lag tomme revisjoner i det hele tatt – utelat dem.

--renumber-revs

Hvis tomme revisjoner er droppet (ved bruk av valget --drop-empty-revs), forandres revisjonsnumrene på de gjenværende revisjonene så det ikke blir mellomrom i den numeriske sekvensen.

--preserve-revprops

Hvis tomme revisjoner ikke droppes, ta vare på revisjonsegenskaper (loggmelding, forfatter, dato, egendefinerte egenskaper og så videre) for disse tomme revisjonene. Tomme revisjoner vil ellers bare inneholde det originale tidspunktet og en generert loggmelding som indikerer at denne revisjonen ble tømt av svndumpfilter.

Selv om svndumpfilter kan være veldig nyttig og sparer masse tid, er det dessverre et par ting å passe på. For det første er dette verktøyet overfølsom for sti-semantikk. Legg merke til om stiene i dumpfila er spesifisert med eller uten skråstreker i starten. Dette vil du se i Node-path og Node-copyfrom-path i headerne.

…
Node-path: spreadsheet/Makefile
…

Hvis stiene har innledende skråstreker, skal du også ha innledende skråstreker i stiene som du leverer til svndumpfilter include og svndumpfilter exclude (og hvis de ikke har det, skal du ikke gjøre det). Videre, hvis dumpfila di har inkonsekvent bruk av innledende skråstreker av en eller annen grunn,^[30] bør du normalisere disse stiene så de alle enten har eller mangler innledende skråstreker.

I tillegg kan kopierte stier gi deg litt trøbbel. Subversion støtter kopioperasjoner i depotet, der en ny sti blir opprettet ved å kopiere en allerede eksisterende sti. Det er mulig at på et eller annet punkt i livsløpet til depotet blir ei fil eller katalog kopiert fra en plass som svndumpfilter utelater, til en plass som programmet inkluderer. For å gjøre dumpdataene selvforsynt, må svndumpfilter vise tilleggingen av den nye stien – inkludert innholdet av alle filer opprettet av kopieringen – og ikke vise denne tilleggingen som en kopiering fra en kilde som ikke eksisterer i den filtrerte dumpdatastrømmen. Men fordi dumpformatet i Subversion bare viser hva som ble forandret i hver revisjon, kan det være at innholdet i kilden for kopien ikke er tilgjengelig. Hvis du har mistanke om at du har denslags kopier i depotet ditt, vil du kanskje tenke gjennom valget ditt av inkluderte/utelatte stier på nytt.

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 i uversjonerte egenskaper – unntatt av en administrator.

Hvis en loggmelding må forandres av en administrator, kan dette gjøres ved å bruke svnadmin setlog. Denne kommandoen forandrer loggmeldingen (svn:log-egenskapen) på en gitt revisjoen i et depot, ved å lese den nye verdien fra ei fil.

$ echo "Her er den nye, korrekte loggmeldingen" > nylogg.txt
$ svnadmin setlog mittdepot nylogg.txt -r 388

Kommandoen svnadmin setlog alene er fortsatt bundet av den samme beskyttelsen mot å modifisere uversjonerte egenskaper som en klient på en annen maskin er – påhakningsskriptene pre-revprop-change og post-revprop-change blir fortsatt aktivisert og må derfor settes opp til å godta denne typen forandringer. Men en administrator kan gå rundt denne beskyttelsen ved å angi valget --bypass-hooks til svnadmin setlog-kommandoen.

	Advarsel
	Men husk at ved å omgå påhakningsskriptene unngår du også utføring av ting som meldinger via email om forandringer i egenskaper, backupsystemer som følger med på egenskapsforandringer og så videre. Med andre ord, vær meget forsiktig med hva du forandrer og hvordan du forandrer det.