Hovedmålet for et versjonskontrollsystem er å muliggjøre samarbeidsredigering og deling av data. Men forskjellige systemer bruker forskjellige strategier for å oppnå dette. Det er viktig å forstå disse forskjellige strategiene av et par grunner. For det første vil det hjelpe deg å sammenlige og danne kontrast mot andre systemer som ligner på Subversion. Utenom det, vil det også hjelpe deg til å effektivisere bruken av Subversion, siden Subversion selv støtter et par forskjellige arbeidsmåter.
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å!
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.
Problemet med “lås-rediger-lås opp”-metoden er at den er ganske restriktiv, og blir ofte en hindring for brukerne:
-
Låsing kan medføre administrative problemer. Noen ganger hender det at Harry låser ei fil og glemmer den. I mellomtiden, fordi Sally fortsatt venter på å få redigere fila, har hun hendene bundet. Og så drar Harry på ferie. Nå må Sally få en administrator til å fjerne Harrys lås. Situasjonen ender opp med mange forsinkelser og mye bortkastet tid.
-
Låsing kan forårsake unødvendig serialisering. Hva hvis Harry redigerer begynnelsen av en tekstfil, og Sally rett og slett bare vil redigere slutten av den samme fila? Disse forandringene overlapper ikke i det hele tatt. De kan enkelt redigere fila samtidig, og ingen stor skade vil skje, såfremt forandringene ble flettet fint sammen. Det er ingen vits i at de må vente på tur i denne situasjonen.
-
Låsing kan skape en falsk følelse av trygghet. Tenk deg at Harry låser og redigerer fil A, mens Sally samtidig låser og redigerer fil B. Men hva hvis A og B er avhengig av hverandre, og forandringene som er lagt til hver av filene er semantisk inkompatible med hverandre? Plutselig virker ikke A og B sammen mer. Låsesystemet var ikke i stand til å forhindre problemet – men skapte likevel en falsk følelse av trygghet. Det er lett for Harry og Sally å tenke seg at ved å låse filer, starter hver av dem en trygg, isolert oppgave, og de bryr seg dermed ikke med å diskutere deres inkompatible forandringer på et tidligere tidspunkt. Låsing blir ofte en erstatning for skikkelig kommunikasjon.
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.
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.