Defcon Kaklkaklkekl (Wiki)

====== Versjonskontroll ====== Dette dokumentet beskriver versjonskontroll, subversion, og klientprogramvare for subversion. Slides som benyttes ved presentering av dette ligger på [[http://defcon.no/files/svnpresv2.pdf]] ===== Hva er versjonskontroll? ===== Hensikten med et versjonskontrollsystem er i første rekke å legge til rette for at flere kan samarbeide om å redigere på, og dele informasjon. Som navnet tilsier, innebærer også versjonskontroll at alle endringer som lagres inn i systemet, blir håndtert som separate versjoner, og gir dermed muligheten til å se endringer og gå tilbake til tidligere lagrede utgaver av informasjon. {{ norsk:guider:eksempel4.png }} ===== Utfordringen ===== Hvorfor benytter vi slike systemer for å håndtere versjoner og deling av informasjon? Man kunne jo bare lage kopier av informasjonen? La oss ta for oss et par eksempler på problemstillingen. ==== Eksempel 1 (separate kopier) ==== Arne og Bente som samarbeider om å skrive på et dokument. Det hele starter ved at Arne oppretter en fil som han skriver inn sin innledende tekst i, og lagrer. Denne filen sender han over i en mail til Bente, som leser igjennom, og begynner å legge til tekst. Bente sender så sin __versjon__ av filen tilbake til Arne, som kan fortsette å jobbe med filen. På denne måten er det bare en som jobber med dokumentet om gangen, og det oppstår en stor mengde kopier av mer eller mindre samme fil. For at man skal holde oversikt over endringer, er Arne og Bente temmelig avhengig av at den ene ikke gjør endringer i den andres tekst, uten å varsle om dette. Temmelig lite effektivt, og lite robust. {{ norsk:guider:eksempel1.png }} ==== Eksempel 2 (felles kopi) ==== Arne og Bente fant ut at å sende filene sine frem og tilbake var lite effektivt, så de får opprettet en server-plass der de begge har tilgang, og legger filene sine der. Nå sitter de på et begrenset antall filer, men problemene er fremdeles ikke borte. Nå kan de bare jobbe en om gangen på samme fil, og de må fortsatt varsle hverandre hvis den ene endrer på den andres tekst. Mens de jobber med filene sine, åpner Arne filen readme.txt, og begynner å legge til en seksjon i bunnen av filen. Bente sitter og titter igjennom filene, og innser at det er en graverende feil i den første seksjonen. Så hun åpner filen, retter opp i feilen, og lagrer. Etter en halvtimes tid gjør Arne seg ferdig med det han la til, og lagrer filen. Dermed er den viktige rettingen som Bente gjorde borte, Arne overskrev rett og slett hennes endringer! Og siden de ikke har noen automatisk historikk blir ikke slike feil oppdaget. {{ norsk:guider:eksempel2.png }} ==== Eksempel 3 (Glemte endringer) ==== Christer sitter og utvikler en web-side, som han begynner å bli ganske fornøyd med. I begynnelsen var han flink til å lage backup av filene sine, men siden ting har gått så bra, har han sluttet med det. En dag bestemmer han seg for å teste et Ajax-bibliotek som gir flotte funksjoner som han vil bruke på forsiden sin. Han bruker en uke på å få dette til å fungere, men må til slutt gi opp. Nå har han en webside som __var__ flott, men ikke lenger fungerer, og den nyeste backupen hans er alt for gammel til å inneholde særlig mye nyttig. ===== Løsningen ===== Det vi ønsker å oppnå er altså samskriving på dokumenter, sikring mot overskriving, og en lettbetjent form for backup (altså muligheten til å gå tilbake i tidligere utgaver/versjoner). Dette er hva begrepet versjonskontroll innebærer. Det finnes flere forskjellige variasjoner over hvordan dette håndteres, og her fokuseres det på såkalt sentralisert versjonskontroll med revisjonshåndtering. Dette innebærer at all informasjon som skal versjonshåndteres plasseres i et sentralt lager (eng. __repository__, forkortet //repo//), som man benytter kontrollprogramvare for å få tilgang til. Når man oppretter et versjonskontrollert prosjekt benytter man verktøyene til å __importere__ et opprinnelig sett med kataloger og/eller filer inn i et sentralt repository. Før man begynner å arbeide med informasjonen, henter man så ut en __arbeidskopi__, som er en lokal, kontrollert kopi av informasjonen i repository. Etter denne initielle uthentingen (eng. __checkout__) begynner man å jobbe med informasjonen, og når man er ferdig med jobbingen, legger man sine endringer opp til repo gjennom en innsjekk (eng. __checkin__). Versjonskontrollsystemet fletter da endringene inn i den allerede eksisterende informasjonen, og lagrer endringshistorikk, som gjør det mulig å gå bakover i gamle versjoner, samt se forskjell mellom versjoner. Om flere skal samarbeide om redigering av informasjon, oppretter hver enkelt sin arbeidskopi som de jobber mot. Før en arbeidssesjon gjør man en oppdatering av arbeidskopien, slik at man blir synkronisert med innholdet i repository. Deretter arbeider man som normalt, og sjekker inn når vesentlige endringer er gjort, eller arbeidssesjonen er ferdig. Verktøyene vil automatisk ta seg av at flere personer endrer på samme fil, og også håndtere konflikter der flere har endret på samme plass i samme fil. ==== Eksempel 4 (versjonskontroll) ==== Etter å ha mailet dokumenter frem og tilbake, og deretter å ha jobbet en stund med et felles lager, blir Arne og Bente lei av at den ene overskriver den andres endringer hele tiden, og at det tar så lang tid å vente på at den andre skal bli ferdig før man kan fortsette. De skaffer derfor et verktøy som gir versjonskontroll av de sentralt lagrede filene. De setter opp dette, og benytter verktøyet til å lage hver sin av filene. Dette medfører at vi får flere kopier av filene igjen, men i et begrenset antall (i dette tilfelle, tre). Arne og Bente kan nå arbeide på hver sin kopi av filene, og er dermed ikke avhengig av å vente på den andre, siden ingenting i arbeidskopien til den ene kan overskrives i arbeidskopien til den andre. Når de er ferdige med å gjøre endringer, eller har gjort så pass vesentlige endrigner at det er på tide å oppdatere for den andre, benyttes versjonskontrollvertøyet til å kopiere endringer i arbeidskopi tilbake til den sentrale plasseringen. Men isteden for å overskrive de gamle versjonene av filene, sørger verktøyet for å //flette// endringene inn i den sentrale kopien, og lagre en logg over hva som ble endret. {{ norsk:guider:eksempel4.png }} ===== Sentrale konsepter ===== * **Repository**: Sentralt lager for informasjon (filer, kataloger), som gjennom versjonskontrollsystemet tar vare på historikk, logger og revisjoner. * **Arbeidskopi** //(Working copy)//:En lokal kopi av innholdet i repository (eller deler av repository). Alt arbeid man gjør med informasjon som er versjonskontrollert skal gjøres på (eller opp mot) en arbeidskopi. Katalogen som en arbeidskopi havner i vil inneholde kontrolldata som holder oversikt over hvilket tidspunkt siste uthenting ble gjort fra repository, hvilke filer som endres og lignende. * **Import**: Når man legger informasjon inn i et repository for første gang, kalles dette en import. All innkopiering av nye data, hvor de nye data ikke kommer fra en arbeidskopi, er i grunn import. * **Checkout**: Uthenting av en ny arbeidskopi gjøres gjennom en checkout. Checkout kan normalt sett gjøres mot hele repository, eller mot avgrensede deler. * **Update**: En update gjør (som ordet tilsier) en oppdatering av arbeidskopi. Dette bringer arbeidskopien til en synkronisert tilstand mot repository. Versjonskontrollverktøyene vil under oppdatering også håndtere eventuelle konflikter mellom endringer i arbeidskopi og nyere innhold fra repository. Norsk begrep for dette er rett og slett oppdatering. * **Commit/Checkin**: Når endringer er gjort i arbeidskopi, benyttes (relativt) enkle verktøy til å gjøre en commit. Dette innebærer å overføre de lokale endringene opp til repository, hvor de flettes inn. Norsk begrep som benyttes her er innsjekk. * **Konflikt**: Når det gjøres endringer i samme tekst/område i en fil fra flere arbeidskopier, vil det under oppdatering eller innsjekk kunne oppstå konflikter. Forskjellige versjonskontrollsystemer håndterer konflikter på forskjellig måte, men felles for disse er at brukeren vil varsles om konflikten, og få muligheten til å flette inn de endringene som man ønsker å beholde. * **Trunk**: Det er normalt å dele opp et versjonshåndtert prosjekt i en stamme, hvor hovedvekten av endringer skjer, og eventuelt opprette separate kopier hvor eksperimentelle endringer gjøres. Hovedkopien, stammen, er altså det som menes med trunk. * **Branch**: Når man oppretter "avleggere" fra stammen, for å teste ut endringer, eller innføre nye funksjoner som ikke skal være en del av stammen, oppretter man en gren, eller branch. Hvordan forgreninger benyttes varierer fra prosjekt til prosjekt eller mellom brukere, men det er ikke unormalt at avgreinger har begrenset levetid. * **Tag**: Tag, eller på norsk, merke, settes for å markere et fast punkt på innholdet i reopsitory. Dette kan for eksempel være når man offentliggjør en versjon av informasjonen, før ny funksjonalitet innføres, eller ved tidspunkter hvor informasjonen regnes som "stabil". Forskjellige systemer håndterer dette forskjellig, men normalt sett er en "tag" tilgjengelig som en egen kopi av innholdet i repository. Felles for trunk, branches og tags er at versjonskontrollsystemet ikke vil bruke ekstra lagringsplass for å håndtere de separate kopiene. Det er kun endringer i forhold til trunk som vil ta opp lagringsplass. ===== Subversion ===== Det finnes mange systemer for versjonskontroll(([[wp>Revision_control]])) ((aldri __siter__ fra Wikipedia, med mindre temaet er allmenn kjent, eller referansen regnes som triviell)), med forskjellige egenskaper, fordeler og ulemper. Et av disse systemene er subversion. Dette systemet er (som mange andre) en videreutvikling av tidligere versjonskontrollsystemer, spesifikt CVS ((se [[http://www.nongnu.org/cvs/]])) (Concurrent Versions System) som igjen var basert på RCS ((se [[http://agave.garden.org/~aaronh/rcs/tichy1985rcs.html]])) (Revision Control System). Subversion har en del fordeler(([[http://subversion.tigris.org/]])), så som: * Commit operasjoner gjøres atomisk. Dette innebærer at alle deler av innsjekk testes før operasjonen utføres, og selve commit operasjonen utføres ikke med mindre alle deler av commit kan fullføres uten feil. * Alle metadata er vesjonskontrollert. Du kan fortelle subversion at for eksempel tegnsettet i en fil er ISO-formatert, og senere endre denne opplysningen til at UTF8 benyttes, og disse endringene versjonshåndteres sammen med filen. Tilsvarende vil en omdøping av en fil versjonskontrolleres, slik at man kan følge historikken bakover og fremover forbi omdøpingen. * Lokale repositories. Det er enkelt å opprette et subversion repository som er lagret på din egen datamaskin, for å gi versjonskontroll og enkel backup av informasjon. * Et vell av kommunikasjonsformer. Subversion kan benytte mange former for kommunikasjon når systemet brukes med sentrale repositories. Vanlig brukte kommunikasjoner er HTTP, HTTPS, SSH og rsync overføring. I tillegg har nyere versjoner av subversion muligheten til å kjøre i "standalone mode", hvor det benyttes en egenutviklet kommunikasjonsform. * Bred tilgjengelighet. Kommandolinjeklienten er tilgjengelig for de aller fleste operativsystemer, serverdelen fungerer på en stor del av de, og det er utviklet alternative grensesnitt for de mest brukte operativsystemer. * Branches og tags er håndtert på enklest mulig måte. I bunn og grunn har ikke subversion noen egen funksjonalitet for å håndtere branches og tags, men hånterer isteden dette gjennom kopi-operasjoner. En grundigere gjennomgang av subversion oppnår vi best ved å gjøre en praktisk bruk av systemet. Vi velger nå å basere oss på en grafisk klient for Windows, fremfor å bruke kommandolinjen i første omgang. ===== TortoiseSVN ===== TortoiseSVN (([[http://tortoisesvn.tigris.org/]]))er klientprogramvare for subversion utviklet for å kjøre på Windows, og integreres med Windows Explorer (Utforsker). Slik sett benyttes tortoise ikke som ett frittstående program, men betjenes mer naturlig direkte mot filer og kataloger. Tortoise gir direkte informasjon om status på filer ved å legge etiketter, visuelle symboler, på filens ikoner som forteller status. Integrasjonen gjør at selv de operasjonene som er mest plundrete med subversion, blir så enkelt som å bruke høyre musetast. Flytting av filer og kataloger er typisk operasjoner som man glemmer seg bort og gjør uten å ta hensyn til versjonskontroll, med Tortoise gjøres det ved å dra ikoner med høyre musetast og velger "SVN Move...". TortoiseSVN støtter alle kommunikasjonsformene som subversion kan benytte og har gode dialoger for innsjekk og oppdateringer. I tillegg gir TortoiseSVN veldig god oversikt gjennom sine verktøy for repository-browsing, differansevisning, konflikthåndtering, samt verktøy for å lage grafer over versjonshistorikk. ==== Opprette et lokalt repository ==== Lokalt repository benyttes hvis kun du skal arbeide på filer, som ligger lagret på din maskin. Dette er for eksempel nyttig hvis du har et mindre prosjekt som du vil ha versjonskontroll på, eller ønsker å benytte SVN som en form for backup. Dersom du skal jobbe mot et sentralt repository som du kobler til via et nettverk, kan du hoppe forbi dette punktet. For å opprette et lokalt repository, bør du aller først starte med å opprette en katalog på en helt annen plass enn der du vil plassere arbeidskopien din. Repo'et vil putte filene sine rett inn i katalogen du gjør "Create repo" operasjonen på. Vi oppretter en katalog på C:\SVN\Repo som vi ønsker å bruke til dette formålet. Deretter høyreklikker vi på katalogen, og velger "TortoiseSVN\Create repository here.." {{ norsk:guider:createrepo.png?200 }} Det kommer da opp en dialog som spør hvilken lagringstype som skal benyttes. For detaljer rundt de forskjellige formatene, henviser vi til Subversion dokumentasjonen, og nøyer oss med å si at for små prosjekter som lagres lokalt, egner FSFS seg godt {{ norsk:guider:fsselect.png?150 }} Tortoise informerer så om at opprettelsen var vellykket. Åpner du katalogen vil du nå se at det har dukket opp en god samling med filer og kataloger. Alle disse benyttes av subversion i en eller annen form, men til enkel bruk trenger man ikke tenke mer over filene som ligger i Repo katalogen. Videre arbeid skal gjøres mot en arbeidskopi, ikke mot filene som ligger her. Dette er den katalogen som du bør sikre ekstra godt, for eksempel ved å ta backup til en ekstern harddisk eller lignende. ==== Første import ==== Ofte starter et versjonskontrollert prosjekt med noe allerede eksisterende data. I eksempelet vårt jobber vi med en veldig enkel begynnelse på en webside som er bestilt av en kunde. Prosjektet er opprinnelig lagret i en katalog med navnet "Kundeweb", som har to filer som underelementer: index.html og logo.png. Når du importerer filer til et repository, er det vanlig å opprette en katalog for det spesifikke prosjektet, og opprette tre standard kataloger under denne: * branches * tags * trunk Så vi oppretter disse katalogene under Kundeweb katalogen vår, og flytter de opprinnelige filene inn i katalogen trunk, siden disse utgjør den opprinnelige stammen i prosjektet vårt. Vi flytter oss så en katalog opp, og høyreklikker på katalogen Kundeweb. Fra menyen velger vi så TortoiseSVN\Import... {{ norsk:guider:import1.png?210 }} Vi får da opp et dialogvindu hvor vi kan oppgi adressen til det repository vi vil importere til, samt en beskrivende kommentar for importeringen. I URL feltet oppgis full adresse til repository på en av formene som TortoiseSVN takler. I adressen skal vi passe på å legge til navnet på prosjektet vårt bakerst, slik at vi senere kan benytte samme repository til flere, uavhengige prosjekter. Eksempler på adresser kan være: file:///C:/SVN/Repo/Kundeweb http://svnserver.example.com/repository1/Kundeweb https://svnserver.example.com/repository1/Kundeweb svn://svnserver.example.com/srv/svn/repository1/Kundeweb svn+ssh://svnserver.example.com/srv/svn/repository1/Kundeweb Her ser man at Kundeweb legges til på slutten, som navn på prosjektet. Repo'et benytter felles revisjonsnumre, så for å holde oversikt over hva som endres hvor i historikk, bør man legge inn en forklarende kommentar på importeringen. {{ norsk:guider:import2a.png?230 }} Etter å ha klikket OK, kopieres filer over til repository ((enkelte eksterne repositories krever brukernavn og passord)), og du får en rapport over hva som ble overført. Etter at første importering av vårt prosjekt er unnagjort, bør vi faktisk kvitte oss med den katalogen vi gjorde importeringen med. Videre arbeid skal jo tross alt skje mot en arbeidskopi, og den katalogen vi importerte fra blir ikke automatisk til en arbeidskopi. Putt katalogen i papirkurven, flytt den til et helt annet sted eller gi den et nytt navn om du vil ta vare på den. Vi har uansett en komplett kopi liggende i subversion. {{ norsk:guider:import3.png?300 }} ==== Checkout fra repository ==== Alt arbeid mot subversion gjøres altså fra en arbeidskopi, og en slik opprettes ved å gjøre en checkout operasjon. Checkout kan normalt sett gjøres fra hvilken som helst gren i et subversion repository tre, og dette gjør vi oss nytte av nå. Isteden for å lage en arbeidskopi av hele innholdet i repository, henter vi kun ut en arbeidskopi av trunk. Steg en i en checkout er å finne en plass vi vil ha innholdet fra operasjonen lagret. Vi oppretter en katalog som vi igjen kaller Kundeweb, og går inn i denne katalogen. Inne i katalogen høyreklikker vi i det tomme feltet, og velger SVN Checkout. {{ norsk:guider:checkout1.png?150 }} Vi får da opp en dialog hvor vi fyller inn adresse til prosjektets trunk. Eksempler på adresser, basert på import-eksemplene kan være: file:///C:/SVN/Repo/Kundeweb/trunk http://svnserver.example.com/repository1/Kundeweb/trunk https://svnserver.example.com/repository1/Kundeweb/trunk svn://svnserver.example.com/srv/svn/repository1/Kundeweb/trunk svn+ssh://svnserver.example.com/srv/svn/repository1/Kundeweb/trunk {{ norsk:guider:checkout2.png?230 }} Siden vi høyreklikket inne i katalogen vi ønsket å ha filer i, er resten av dialogboksen normalt sett fornuftig fylt ut. Vi kan derfor klikke OK i denne, og får en rapport over operasjonene som blir utført ((se forrige fotnote)). Innholdet i katalogen minner nå om det opprinnelige innholdet, med unntak av TortoiseSVN sine statusemblemer som er lagt til på filene. {{ norsk:guider:checkout3.png?150 }} Dette er nå vår arbeidskopi, og er hvor vi kommer til å gjøre vårt arbeid videre. ==== Update ==== Hver gang det er gjort endringer i repository som ikke er synkronisert inn i din arbeidskopi, skal du gjøre en oppdatering av din arbeidskopi før du begynner å jobbe. Når flere arbeider på samme prosjekt, er det vanskelig å si når noen har gjort endringer (med mindre du kontinuerlig leser logger), så gjør det til en vane å oppdatere hver gang du begynner å arbeide, og etter hver pause. Du skal også passe på å oppdatere før du melder inn dine egne endringer, for å løse eventuelle konflikter før data dyttes til repository. Jobber du alene på et lokal repository er naturlig nok ikke så kritisk, men gjør jevnlig oppdatering til en vane allikevel. Med TortoiseSVN oppdaterer vi ved å høyreklikke på den katalogen som utgjør den del av arbeidskopien som skal oppdateres, og velger SVN update. Dette fungerer også når vi står i katalogen, og velger "Fil" menyen i vinduet, eller høyreklikker i et tomt område av katalogen. En oppdatering kan gjøres på hele arbeidskopien, eller bare deler, for eksempel en enkelt underkatalog eller tilogmed enkeltfiler. Oppdateringen gir deg en rapport over hvilke endringer som ble gjort under oppdateringen. {{ norsk:guider:update1.png?200 }} ==== Endring, tillegg, commit ==== Når du begynner å gjøre endringer på filer som allerede er versjonskontrollert, vil du se at TortosieSVN indikerer alle endrede plasseringer ved å legge på et rødt utropstegn som emblem. Dette er et tydelig varsel om at arbeidskopien ikke lenger er synkronisert med repository, og inneholder lokale endringer. {{ norsk:guider:changes1.png?160 }} For å legge til nye filer, lagrer du rett og slett de nye filene på vanlig måte inn i arbeidskopien, eller du kopierer de inn. Du vil se at de nye filene ikke er versjonskontrollert enda ved at de ikke har noe TortoiseSVN emblem enda. For å legge til filene i repository, markerer du filene, eller eventuelt katalogene, som skal legges til, høyreklikker, og velger TortoiseSVN\Add... {{ norsk:guider:changes2.png?210 }} Du får da opp en dialog hvor du kan velge blant filene som skal legges til. Her kan det være greit å fjerne avkrysning på systemfiler som ikke skal lastes opp, så som "Thumbs.db" og lignende. Etter at du har akseptert valgene for tillegg, vil arbeidskopien din vise nok et nytt emblem, ett blått plusstegn. Dette indikerer at filer er definert som lagt til, men ikke enda overført til repository. Filene lastes nemlig ikke over med en gang, men venter på at du skal gjøre en commit-operasjon. {{ norsk:guider:changes3.png?160 }} Vi har nå gjort såpass store endringer, at vi vil lagre de inn i repository. Først utfører vi en Update operasjon for sikkerhets skyld. Vi høyreklikker i et tomt område av Kundeweb katalogen vår, og velger "SVN Update". Når arbeidskopien nå er synkronisert, høyreklikker vi igjen i et tomt område, og velger "SVN Commit...". {{ norsk:guider:changes4.png?200 }} Vi får opp en dialog som ber om en endringsmelding, og lar oss velge hvilke endringer vi ønsker å ta for oss i denne commit-operasjonen. Siden det er mulig å fjerne kryss fra filer, ser du at man ikke trenger å laste over alle endringer som er gjort i samme commit-operasjon. Endringsmeldingen bør fylles inn så forklarende som mulig, uten at man skriver en avhandling. Det frarådes å ikke bruke endringsmeldinger, disse er veldig nyttige om du senere trenger å finne frem til den revisjonen der en spesiell endring ble gjort! {{ norsk:guider:changes5.png?270 }} Når du så velger OK overføres filene, og endringene oppsummeres. Emblemene på filene som ble sjekket inn endrer seg nå tilbake til grønt OK-merke. ==== Revert ==== Hvis du sitter og arbeider, og gjør en endringer i en fil, og så angrer på endringen som ble gjort, vil det være nyttilg å ha muligheten til å gå tilbake til forrige fungerende versjon. Dette er en __revert__ operasjon. En revert erstatter en lokalt endret fil eller filer med den versjonen som ligger i repository. For å revertere en fil, høyreklikker du på den, velger "TortoiseSVN\Revert.." og klikker OK. Filen er da tilbake til den status den hadde ved forrige commit. ==== Branch og Switch ==== En foregrening kan som tidligere nevnt være nyttig å bruke hvis man skal teste ut endringer som ikke nødvendigvis hører hjemme i stamme-koden, eller hvis man ønsker å ta basis i stammen og føre prosjektet i en annen retning. En branch (gren) må lages fra en fungerende arbeidskopi av stammen. Dette betyr at man må lage forgreiningen før man begynner med grenens spesifikke endringer ut fra stammen. Sørg for at arbeidskopien er synkronisert, ved å gjøre de oppdateringer, reverts og commits som trengs for å få dette til. Når arbeidskopien stemmer med siste revisjon av stammen, finner du frem til høyreklikk-menyen for arbeidskopiens rot-katalog, og velger "TortoiseSVN\Branch/Tag.." fra denne. {{ norsk:guider:branch1.png?160 }} Opp kommer en dialogboks som forteller hvor arbeidskopien er hentet fra, og spør hvor du vil plassere forgreiningen. Adressen i "To URL" feltet er i utgangspunktet identisk med "From WC at URL" informasjonen. Vi sjekket opprinnelig ut fra Kundeweb/trunk, og skal nå putte inn en ny grein, så vi bytter ut "trunk" med "branches", og legger til et fornuftig katalognavn for greina vår bakerst. I dette tilfellet oppgir vi "eksperiment1" som navn på greina. Vi taster også inn en forklarende beskrivelse på hvorfor vi lager en forgreining. {{ norsk:guider:branch2.png?230 }} Nederst i dialogen er det en avkrysning med teksten "Switch working copy to new branch/tag". Hvis vi ikke setter et kryss her, vil arbeidskopien vår forsette å peke mot "trunk" (altså den gamle plasseringen), og commit vil gjøres mot den, isteden for vår nye forgreining. Ved å krysse av for "Switch..." slutter arbeidskopien å peke mot den gamle plasseringen, og peker isteden mot den nye greina. Alle endringer havner da til forgreininga, som igrunn var det vi ville. Vi fikk her introdusert ett nytt subversion-begrep, "switch". Når man utfører en switch-operasjon, endrer man en arbeidskopi slik at den peker mot en ny plassering i subversion. Det er mulig å utføre switch mellom grener, mellom repositories, og tilogmed mellom revisjoner. Når switch utføres, endres alle filer og kataloger i arbeidskopien slik at man er i synk med den plasseringen man gjorde switch mot. En switch-operasjon gjøres fra samme kontekstmeny somm vi valgte "Branch/Tag..." fra, og er faktisk menyelementet rett under dette. ==== Repobrowser ==== TortoiseSVN har ett særlig nyttig verktøy, Repository Browser. Med dette verktøyet kan du bla igjennom og se innholdet av hele repositories. Vinduet til repository browser har et URL-felt som lar deg oppgi direkte adresse til et annet repository enn det arbeidskopien din er hentet fra, hvis du f.eks er nysgjerrig på innholdet i et annet prosjekt. Repository Browser lister opp filene og katalogene som ligger i det valgte repository, den viser hvilken revisjon som holder den nyeste kopien av hver enkelt fil og katalog, hvem som gjorde sist endring, og når. Det er mulig å sortere listen på alle disse elementene. Alle filer har en kontekstmeny på høyreklikk. Her er det mulig å lese logg for innholdet i repository, man kan få se en graf som viser hvor det er opprettet greiner og tags, og det er dette verktøyet du skal benytte dersom du ønsker å slette eller gi nytt navn til en gren, tag eller et prosjekt. Sletting av grener, eller omdøping av prosjekter, bør gjøres så kontrollert som mulig. Derfor er alternativet til å benytte Repository Browser, å bruke den kommandolinjebaserte offisielle subversion klienten. Repository Browser er et lite, enkelt verktøy, men samtidig en av de virkelig store styrkene i TortoiseSVN. {{ norsk:guider:repobroser.png?320 }} ===== Rask intro til kommandolinjeklienten ===== Videre følger en liten veiledning for bruk av kommandolinje verktøyene som følger den offisielle subversion distribusjonen. Innføringen er basert på bruk på en Unix-lik maskin, som Linux eller Mac OS X. En mer utførlig veiledning, og en god gjennomgang, blir presentert på det første HiGLUG møtet i januar hvert år, og notatene/foilene fra disse ligger ute på http://linux.hig.no/ under "Møter". ==== Importer et basis-sett med dokumentasjon/kode o.l. ==== $ mkdir ~/prosjekt $ cd prosjekt $ mkdir branches $ mkdir tags $ mkdir trunk $ -- opprett filer i katalog -- $ cd ~/prosjekt $ svn import . https://subversion.example.com/repository/prosjekt (erstatt adressen her med korrekt adresse til ditt repository) Etter at innholdet er importert repository kan katalogen man opprinnelig opprettet igrunn slettes. Alt arbeid man gjør med innholdet senere, skal gjøres i en arbeidskopi, som hentes ned fra subversion. ==== Kjør checkout på repositoryet ==== Før man kan begynne med versjonskontroll av filer må man kjøre checkout av repositoryet fra Subversion-serveren. På kommandolinjen kan denne kommandoen kjøres: svn co https://subversion.example.com/repository/prosjekt/trunk prosjekt Tast inn brukernavn og -passord om programmet spør om det (erstatt adressen her med korrekt adresse til ditt repository) ==== Ta i bruk Subversion ==== Etter checkout blir det lagd en katalog "prosjekt" som dokumentasjon, kildekode, osv legges under. Når man oppretter en ny fil må denne legges til i repositoryet: $ svn add <fil> Når man neste gang sjekker inn endringer i repositoryet med: $ svn ci vil alle endringer gjort lokalt bli overført til serveren. Hvis man skal oppdatere repositoryet lokalt med endringer andre har gjort og sjekket inn på serveren kjøres: $ svn up Alle kataloger og filer under den katalogen man står vil bli oppdatert. svn up må også kjøres før man sjekker inn noe hvis server-repository ikke er synkronisert med det lokale repositoryet.