Grunnleggende arbeidssyklus
Forrige  Kapittel 2. Grunnleggende bruk  Neste

Grunnleggende arbeidssyklus

Subversion har mange funksjoner, valg og avanserte muligheter, men på en dag-til-dag-basis er oddsene store for at du bare vil bruke et fåtall av dem. I denne seksjonen vil vi gå gjennom de vanligste tingene som du vil komme ut for med Subversion i løpet av en dags arbeid.

En typisk arbeidssyklus ser ut som dette:

Oppdater arbeidskopien din

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:

U foo

Fila foo ble oppdatert (Updated) og mottok forandringer fra serveren.

A foo

Fila eller katalogen foo ble lagt til (Added) i arbeidskopien din.

D foo

Fila eller katalogen foo ble slettet (Deleted) fra arbeidskopien.

R foo

Fila eller katalogen foo ble erstattet (Replaced) i arbeidskopien; det vil si, foo ble slettet og et nytt element med det samme navnet ble lagt til. Selv om de har det samme navnet, anser depotet dem for å være forskjellige objekter med hver sin historie.

G foo

Fila foo mottok nye forandringer fra depotet, mens den lokale kopien av fila inneholdt forandringer gjort av deg. Enten blandet ikke forandringene seg med hverandre, eller de var nøyaktig de samme som dine lokale forandringer, så Subversion klarte å flette (merGe) depotets forandringer uten noen problemer.

C foo

Fila foo mottok forandringer som førte til konflikt (Conflict) med dine egne. Forandringene fra serveren overlapper direkte med dine egne forandringer i fila. Men det er ingen grunn til panikk. Denne overlappingen må bli løst av et menneske (deg); vi diskuterer denne situasjonen senere i dette kapittelet.

Gjør forandringer i 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:

Filforandringer

Dette er den enkleste typen forandring. Du trenger ikke å fortelle Subversion at du har tenkt å forandre ei fil; bare sett i gang med forandringene. Subversion vil bli i stand til å automatisk finne ut av hvilke filer som er blitt forandret.

Forandringer i trestrukturen

Du kan spørre Subversion om å “merke” filer og kataloger for oppførte slettinger, tillegginger, kopieringer eller flytting. Selv om disse forandringene tar plass øyeblikkelig i arbeidskopien din, vil ingen tillegginger eller slettinger skje i depotet før du legger dem inn.

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

Versjonering av symbolske lenker

På plattformer som har støtte for det, kan Subversion versjonere filer av typen symbolsk lenke (“symlink”). En symlink er en fil som oppfører seg som en gjennomsiktig referanse til et annet objekt i filsystemet ved å la programmer lese og skrive til disse objektene indirekte ved å operere på selve den symbolske lenken.

Når en symbolsk lenke legges inn i et Subversiondepot, tar Subversion vare på informasjonen om at filen faktisk var en symlink, sammen med informasjonen om til hvilket objekt lenken “peker”. Når denne symlinken hentes ut til en annen arbeidskopi på et system som støtter det, rekonstruerer Subversion en ekte symbolsk lenke i filsystemet fra den versjonerte symlinken. Men det begrenser ikke på noen måte bruksmulighetene for arbeidskopier på systemer som MS Windows som ikke støtter symlinker. På slike systemer lager Subversion rett og slett en vanlig tekstfil der innholdet er stien dit den originale symlinken pekte. Selv om den fila ikke kan brukes som en symlink på et MS Windows-system, forhindrer den ikke Windowsbrukere fra å utføre andre Subversion-relaterte aktiviteter.

[Advarsel] 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.
svn add foo

Klargjør fila, katalogen eller den symbolske lenken foo for å bli lagt til i depotet. Når du legger inn filene neste gang, vil foo bli et barn av foreldrekatalogen. Legg merke til at hvis foo er en katalog, vil alt under foo også bli klargjort for tillegging. Hvis du bare vil klargjøre bare selve foo, legg til valget --non-recursive (-N).

svn delete foo

Klargjør fila, katalogen eller den symbolske lenken foo for sletting fra depotet. Hvis foo er ei fil eller en lenke, blir den slettet øyeblikkelig fra arbeidskopien. Hvis foo er en katalog, blir den ikke slettet, men klargjort for sletting. Når du legger inn forandringene, vil foo bli slettet fra arbeidskopien og depotet.[3]

svn copy foo bar

Opprett et nytt element bar som en duplikat av foo. bar er automatisk klargjort for tillegging. Når bar blir lagt til depotet under neste innlegging, blir kopieringshistorien lagret (som om den kommer originalt fra foo). svn copy lager ikke mellomliggende kataloger.

svn move foo bar

Denne kommandoen er nøyaktig den samme som å kjøre svn copy foo bar; svn delete foo. Det vil si, bar er klargjort for tillegging som en kopi av foo, og foo blir klargjort for fjerning. svn move lager ikke mellomliggende kataloger.

Forandre depotet uten en arbeidskopi

Tidligere i dette kapitlet sa vi at du må legge inn alle forandringene du gjør for at depotet skal bli i stand til å gjengi disse forandringene. Det er ikke helt sant – det er noen tilfeller som legger inn treforandringer til depotet med en gang. Dette skjer bare når en delkommando opererer direkte mot en URL istedenfor en sti i en arbeidskopi. I særdeleshet, spesifikk bruk av svn mkdir, svn copy, svn move og svn delete kan virke med URLer.

URL-operasjoner oppfører seg på denne måten fordi kommandoer som opererer på en arbeidskopi kan bruke arbeidskopien som et slags “anleggsområde” der du gjør i stand forandringene før du legger dem inn i depotet. Kommandoer som opererer på URLer har ikke denne luksusen, så når du opererer direkte mot en URL, representerer alle de ovennevnte operasjonene en øyeblikkelig innlegging.

Studer forandringene dine

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.

Mamma, se! Uten nettverk!

Alle disse tre kommandoene (svn status, svn diff og svn revert) kan brukes uten nettverkstilgang. Dette gjør det lettvint å behandle forandringene som du holder på med når du er en plass uten nettverksforbindelse, som når du reiser med fly, sitter på toget eller hacker på stranden.

Subversion gjør dette ved å ha et privat lager med urørte versjoner av hver versjonert fil lagret inne i det administrative .svn-området. Dette lar Subversion rapportere – og reversere – lokale forandringer i disse filene uten nettverkstilgang. Dette lageret (kalt “tekstbasen” – “text-base”) tillater også Subversion å sende brukerens lokale modifikasjoner under en innlegging som en pakket delta (eller “forskjell”) mot den urørte kopien. Det å ha dette lageret er en enorm fordel – selv om du har en rask nettforbindelse, er det mye raskere å sende bare forandringene til ei fil istedenfor hele fila til serveren.

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.

svn status

Du vil muligens bruke kommandoen svn status mer enn noen annen Subversionkommando.

CVS-brukere: Vent med oppdateringen!

Du er muligens vant til å bruke cvs update for å se hvilke forandringer du har gjort i arbeidskopien. svn status vil gi deg all informasjonen du trenger om hva som er forandret i arbeidskopien – uten å kontakte depotet og dermed risikere å legge inn nye forandringer publisert av andre brukere.

I Subversion gjør update akkurat det – den oppdaterer arbeidskopien din med alle forandringer som er lagt inn i depotet siden den siste gangen du oppdaterte arbeidskopien. Du må bryte vanen med å bruke update-kommandoen for å se hvilke lokale oppdateringer du har gjort.

Hvis du kjører svn status på toppen av arbeidskopien uten å angi argumenter, vil programmet detektere alle fil- og katalogforandringer som du har gjort. Nedenfor er eksempler på de forskjellige statuskodene som svn status kan returnere. (Legg merke til at teksten etter # i det følgende eksempelet ikke skrives ut av svn status-kommandoen.

  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

I dette utdataformatet skriver svn status fem kolonner med tegn, fulgt av flere blanke tegn, etterfulgt av et fil- eller katalognavn. Den første kolonnen forteller statusen til ei fil eller en katalog og/eller dens innhold. Kodene som kan skrives her er:

A element

Fila, katalogen eller den symbolske lenken element er blitt klargjort for tillegging til depotet.

C element

Fila element er i en tilstand av konflikt. Det betyr at forandringer mottatt fra serveren under en oppdatering overlapper med lokale forandringer som du har i arbeidskopien din. Du må løse denne konflikten før du legger inn dine forandringer i depotet.

D element

Fila, katalogen eller den symbolske lenken element er blitt klargjort for sletting fra depotet.

M element

Innholdet av fila element er blitt forandret.

R element

Fila, katalogen, eller den symbolske lenken element er blitt klargjort for å erstatte element i depotet. Dette betyr at objektet først blir slettet, deretter blir et annet element lagt til, alt innenfor en enkelt revisjon.

X element

Katalogen element er uversjonert, men er relatert til en ekstern definisjon i Subversion. For å finne ut mer om “externals”-defineringer, se “Externals Definitions”.

? element

Fila, katalogen eller den symbolske lenken element er ikke under versjonskontroll. Du kan bli kvitt spørsmålstegnene ved å enten angi --quiet (-q)-valget til svn status, eller sette svn:ignore-egenskapen på foreldrekatalogen. For mer informasjon om ignorerte filer, se “Ignoring Unversioned Items”.

! element

Fila, katalogen eller den symbolske lenken element er under versjonskontroll men mangler eller er ukomplett på en eller annen måte. Elementet kan mangle hvis det er fjernet ved bruk av en kommando utenfor Subversions kontroll. I tilfellet med en katalog, kan den være ukomplett hvis du har avbrutt en uthenting eller oppdatering. En rask svn update vil hente fila eller katalogen på nytt, eller en svn revert vil legge tilbake en manglende fil.

~ element

Fila, katalogen eller den symbolske lenken element er lagret i depotet som en type objekt, men det som faktisk er i arbeidskopien er en annen type. For eksempel kan Subversion ha ei fil i katalogen, men du fjernet fila og opprettet en katalog på samme plassen uten å bruke kommandoen svn delete eller svn add.

I element

Fila, katalogen eller den symbolske lenken element er ikke under versjonskontroll, og Subversion er satt opp til å ignorere den under operasjonene svn add, svn import og svn status. For mer informasjon om ignorerte filer, se “Ignoring Unversioned Items”. Merk at dette symbolet bare dukker opp hvis du spesifiserer valget --no-ignore til svn status – ellers ville fila bli ignorert og ikke listet i det hele tatt!

Den andre kolonnen forteller statusen på egenskapene til ei fil eller katalog (se “Egenskaper” for mer informasjon om egenskaper). Hvis en M viser seg i den andre kolonnen, er egenskapene blitt modifisert. Hvis en C kommer til syne i den kolonnen, er egenskapene for fila i en konflikt som må løses før forandringene kan legges inn i depotet. Ellers vil et blankt tegn bli skrevet.

Den tredje kolonnen vil bare vise blanktegn eller en L som betyr at Subversion har låst katalogens .svn-arbeidsområde. Du vil se en L hvis du kjører svn status i en katalog hvor en svn commit er i gang – kanskje mens du redigerer loggmeldingen. Hvis Subversion ikke kjører, ble Subversion sannsynligvis avbrutt og låsene må frigjøres ved å kjøre svn cleanup (mer om det senere i dette kapitlet).

Den fjerde kolonnen vil bare vise blanktegn eller en + som betyr at fila eller katalogen er klargjort for tillegging eller er modifisert med en historie lagt til i tillegg. Dette skjer vanligvis når du bruker svn move eller svn copy på ei fil eller katalog. Hvis du ser A  +, betyr det at elementet er klargjort for tillegging med historie. Det kan være ei fil eller roten på en kopiert katalog. + betyr at elementet er en del av et katalogtre klargjort for tillegging med historie, det vil si at en forelder ble kopiert, og den følger bare med på lasset. M  + betyr at elementet er en del av et katalogtre klargjort for tillegging med historie, og det har lokale forandringer. Når du legger det inn, vil først forelderen bli lagt til med historie (kopiert), noe som betyr at denne fila automatisk vil eksistere i kopien. Deretter blir de lokale forandringene lagt inn i kopien.

Den femte kolonnen vil bare vise blanktegn eller en S. Dette viser at fila eller katalogen er blitt byttet om fra stien som resten av arbeidskopien bruker (ved bruk av svn switch) til en gren.

Den sjette kolonnen viser informasjon om låser, som er nærmere forklart i “Locking”. (Dette er ikke de samme låsene som de som vises som en L i den tredje kolonnen; se Three meanings of “lock”.)

Hvis du gir en spesifikk sti til svn status, gir den deg informasjon om dette elementet alene:

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

svn status har også valget --verbose (-v), som vil vise deg statusen til hvert eneste element i arbeidskopien, selv om det ikke er blitt forandret:

$ 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

Dette er den “lange formen” av utdata fra svn status. Den første kolonnen forblir den samme, men den andre kolonnen viser arbeidsrevisjonen til elementet. Den tredje og fjerde kolonnen viser revisjonen elementet sist ble forandret i, og hvem som gjorde det.

Ingen av kjøringene av svn status ovenfor kontakter depotet, de virker bare lokalt ved å sammenligne metadataene i .svn-katalogen med arbeidskopien. Til slutt er det --show-updates (-u)-valget, som kontakter depotet og legger til informasjon om ting som er utdatert:

$ 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

Legg merke til de to asteriskene: Hvis du skulle kjøre svn update på dette tidspunktet, ville du motta forandringer til README og trout.c. Dette gir deg nyttig informasjon – du må oppdatere og få serverforandringene for README før du legger inn filene, ellers vil depotet avslå innleggingen fordi den ikke er oppdatert. (Mer om dette temaet senere.)

svn diff

En annen måte å undersøke forandringene dine er med kommandoen svn diff. Du kan finne ut nøyaktig hvordan du har forandret på ting ved å kjøre svn diff uten argumenter, noe som lister ut filforandringer i unified diff-format:[4]

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

Kommandoen svn diff produserer disse utdataene ved å sammenligne dine arbeidsfiler mot de lagrede “urørte” kopiene i .svn-området. Filer klargjort for tillegging blir vist som om all teksten er lagt til, og filer klargjort for sletting vises som om all teksten er slettet.

Utdataene blir vist i unified diff-format. Det vil si at slettede linjer vises med en - i begynnelsen av linjen, og linjer lagt til har en + i begynnelsen. svn diff skriver også filnavn og informasjon om filposisjon nyttig for programmet patch, så du kan generere “patcher” ved å omdirigere utdataene fra diff til ei fil:

$ svn diff > patchfil

Du kan for eksempel sende denne patchfila til en annen utvikler så han kan kontrollere eller teste den før den legges inn i depotet.

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

Løse konflikter (Flette inn andres forandringer)

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:

  • Subversion skriver en C under oppdateringen, og husker at fila er i en konflikttilstand.

  • Hvis Subversion anser fila å være av en flettbar type, plasserer den konfliktmerker – spesielle strenger med tekst som skiller “sidene” av konflikten – inn i fila for å vise de overlappende områdene visuelt. (Subversion bruker svn:mime-type-egenskapen for å bestemme om ei fil er mulig å flette ved hjelp av kontekst- og linjebasert fletting. Se “File Content Type” for å lære mer.)

  • For hver fil som har en konflikt plasserer Subversion opp til tre ekstra filer i arbeidskopien din:

    filnavn.mine

    Dette er din fil som den var da den eksisterte i arbeidskopien din før du oppdaterte arbeidskopien – det vil si uten konfliktmerker. Denne fila har dine seneste forandringer og ingenting annet. (Hvis Subversion avgjør at fila ikke er flettbar, blir ikke .mine-fila opprettet, siden den ville vært identisk med arbeidsfila.)

    filnavn.rGAMMELREV

    Dette er den fila som var BASE-revisjonen før du oppdaterte arbeidskopien. Det vil si den fila som du hentet ut før du gjorde dine seneste redigeringer.

    filnavn.rNYREV

    Dette er den fila som Subversionklienten nettopp mottok fra serveren når du oppdaterte arbeidskopien. Denne fila samsvarer med HEAD-revisjonen av depotet.

    Her er GAMMELREV revisjonsnummeret til fila i ditt .svn-område og NYREV er revisjonsnummeret til HEAD i depotet.

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:

  • Flette teksten med konflikt “for hånd” (ved å studere og redigere konfliktmerkene i fila).

  • Kopiere en av de midlertidige filene over arbeidsfila di.

  • Kjøre svn revert <filnavn> for å skrote alle dine lokale forandringer.

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

Løse konflikter for hånd

Å flette konflikter for hånd kan være ganske skremmende den første gangen du prøver det, men med litt øvelse kan det bli like lett som å ramle av en sykkel.

Her er et eksempel. På grunn av dårlig kommunikasjon redigerer både du og Sally, din kollega, fila sandwich.txt samtidig. Sally legger inn sine forandringer, og når du oppdaterer arbeidskopien din får du en konflikt og vi må redigere sandwich.txt for å løse konfliktene. Først, la oss ta en kikk på fila:

$ 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

Strengene med “mindre enn”-tegn, likhetstegn og “større enn”-tegn er konfliktmerker, og er ikke del av de aktuelle dataene i konflikt. Du vil vanligvis forsikre deg om at de er fjernet fra fila før din neste innlegging. Teksten mellom de to første settene med merker er satt sammen av de forandringene du gjorde i konfliktområdet:

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

Teksten mellom det andre og tredje settet av konfliktmerker er teksten fra Sallys innlegging:

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

Vanligvis vil du ikke ønske å bare slette konfliktmerkene og Sallys forandringer – hun kommer til å bli voldsomt forbauset når smørbrødet ankommer og det ikke er det hun ville ha. Så det er nå du tar opp telefonen eller går til andre enden av kontoret og forklarer til Sally at du får ikke sauerkraut fra en italiensk ¤deli.[6] Når dere er blitt enige om forandringene du vil legge inn, rediger fila din og fjern konfliktmerkene.

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

Nå kan du kjøre svn resolved, og du er klar til å legge inn forandringene dine:

$ svn resolved sandwich.txt
$ svn commit -m "Gå i gang med å bruke mitt smørbrød, bort med Sallys redigeringer."

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

Hvis du blir forvirret mens du redigerer fila med konflikt, kan du alltids konsultere de tre filene som Subversion lagde for deg i arbeidskopien din – inkludert fila di sånn som den var før du oppdaterte. Du kan til og med bruke et tredjeparts interaktivt fletteverktøy for å studere de tre filene.

Kopiere ei fil over arbeidsfila din

Hvis du får en konflikt og bestemmer deg for å forkaste endringene dine, trenger du bare å kopiere ei av de midlertidige filene laget av Subversion over fila i arbeidskopien din:

$ 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

Bruke svn revert

Hvis du får en konflikt og under undersøkelsen bestemmer deg for å forkaste endringene dine og starte på nytt, bare reverser forandringene dine:

$ svn revert sandwich.txt
Tilbakestilte «sandwich.txt»
$ ls sandwich.*
sandwich.txt

Legg merke til at når du reverserer ei fil i konflikt, trenger du ikke å kjøre svn resolved.

Legg inn forandringene dine

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


[3] Selvfølgelig, ingenting blir noensinne totalt slettet fra depotet – bare fra HEAD i depotet. Du kan få alt tilbake ved å hente ut (eller oppdatere arbeidskopien til) en tidligere revisjon i forhold til den som ble slettet.

[4] Subversion bruker sine egne interne diffrutiner, som produserer diff-format som standard. Hvis du vil ha utdataene fra diff i et annet format, spesifiser et eksternt diffprogram ved å bruke --diff-cmd og legg til alle flagg du vil trenge ved å bruke --extensions-bryteren. For eksempel, for å se lokale forskjeller i fila foo.c i context format mens forandringer i blanktegn blir ignorert, kan du kjøre svn diff --diff-cmd /usr/bin/diff --extensions '-bc' foo.c.

[5] Du kan alltids fjerne de midlertidige filene selv, men gidder du egentlig det når Subversion kan gjøre det for deg? Det var det vi trodde.

[6] Og hvis du spør dem om det, kan det hende de bærer deg ut av byen på en planke.

Forrige  Opp  Neste
Innledende uthenting  Hjem  Studere historien