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.