(toiminnot)

hwechtla-tl: Subversion

Kierre.png

Mikä on WikiWiki?
nettipäiväkirja
koko wiki (etsi)
viime muutokset


http://subversion.tigris.org/

Subversion on varsin hyvin tehty versionhallintaohjelma. (On varmaankin syytä mainita, että katseltuani GNU archia totesin sen olevan joka suhteessa parempi, joten aion jättää käyttämättä subversionia.)

Kaikki eivät tiedä, mitä versionhallinta tarkoittaa. Jopa monelle kokeneelle tietokoneenkäyttäjälle versionhallinta on tuntematon käsite. Lyhyesti sanottuna versionhallintatyökalut auttavat säilyttämään tuotoksista koko niiden kehityshistorian, pitämään yllä useampia yhtaikaisia versiolinjoja, vertailemaan eri versioita keskenään, siirtämään muutoksia versioiden välillä ja säilyttämään metatietoa (kuten että kuka on muuttanut mitäkin kohtaa) muutoksista. Lisäksi jotkin versiohallintaohjelmat auttavat ihmisten yhteistyötä, ja helpottavat myös yhden ihmisen vaivaa työstää samaa projektia useammasta paikasta.

Versionhallintaohjelmilla on ratkaistavanaan kaksi perustavanlaatuista ongelmaa, ensinnäkin se, miten säilytetään projektin kehityshistoria tilatehokkaasti ja käyttökelpoisesti, ja toisekseen (ja tärkeämpänä), miten estetään ihmisiä tuhoamasta vahingossa toistensa muutoksia. Esimerkiksi yrityksissä, joissa käytetään vain jaettuja tiedostojärjestelmiä dokumenttien / ohjelmien yhteistyöstöön, joudutaan usein delegoimaan tiedostojen "pääomistuksia" tietyille henkilöille, jottei tiedostoa vahingossa muokkaisi kaksi ihmistä yhtaikaa.

Tämän jälkemmäisen ongelman ratkaisuun on kaksi mallia: rajoittava, mutta yksinkertainen lukitusmalli ja salliva, mutta monimutkaisempi yhdistelymalli. Lukitusmalli ei itse asiassa eroa olennaisesti jaetun tiedostojärjestelmän tapauksesta ja useimmat kaupalliset versionhallintajärjestelmät soveltavat sitä - ehkä siksi, että se on helppo toteuttaa? Yhdistelymalli tukee tosissaan hajautettua yhteistyöstöä ja osoittaa jännittävällä tavalla, miten historian säilyttäminen on tärkeää dokumenttien yhteistyöstölle.

Ongelmatilanne on siis tämä:

  1. käyttäjä 1 alkaa muokata tiedoston versiota A ja tuottaa siitä uuden version, version B.
  2. sillä aikaa käyttäjä 2 alkaa myös muokata versiota A ja tuottaa siitä version C.
  3. käyttäjä 1 tallettaa version B.
  4. käyttäjä 2 tallettaa version C ja tuhoaa B:ssä olleet muutokset. Au!

Lukitusmalli ratkaisee sen näin:

  1. käyttäjä 1 aikoo muokata versiota A. Hän lukittaa tiedoston itselleen.
  2. käyttäjä 2 haluaa myös muokata tiedostoa. Hän yrittää lukittaa tiedoston itselleen, mutta saa virheilmoituksen, sillä käyttäjä 1 on jo lukittanut tiedoston.
  3. käyttäjä 1 tekee versionsa B ja tallettaa sen. Tällä aikaa käyttäjä 2 istuu käsiensä päällä ja syljeskelee kattoon. Tallennettuaan käyttäjä 1 vapauttaa lukon.
  4. nyt käyttäjä 2 voi lukittaa tiedoston itselleen ja alkaa muokata versiosta B versiota C.

Yhdistelymallissa taas homma menee näin:

  1. käyttäjä 1 muokkaa versiosta A version B.
  2. käyttäjä 2 muokkaa samaan aikaan versiosta A version C.
  3. käyttäjä 1 tallettaa version B.
  4. käyttäjä 2 yrittää tallettaa version C, mutta saa ilmoituksen, että tiedosto on muuttunut tällä välillä ja muutokset on yhdisteltävä.
  5. niinpä hän hakee A:n ja B:n väliset muutokset. Ne yhdistetään C:in, jolloin syntyy uusi versio D, joka sisältää sekä B:hen että C:hen tehdyt muutokset.
  6. käyttäjä 2 tallettaa version D.

Yhdistelymalli edellyttää, että versionhallintajärjestelmä pystyy aina hakemaan mielivaltaisen vanhoja muutoslitanioita yhdistelyä varten. Siinä jokaisella käyttäjällä on, määritelmän mukaan, oma paikka, jossa hän tekee muutoksia rauhassa muilta käyttäjiltä. Niinpä esimerkiksi subversionissa jokainen käyttäjä hakee versionhallintajärjestelmästä itselleen oman leikkialueen, työstöhakemiston. Eri työstöhakemistot sisältävät eri versioita tiedostoista sen mukaan, milloin ne on viimeksi päivitetty.

Tämä saattaa kuulostaa turhalta vaivalta, mutta kun versionhallintaa on käyttänyt jonkin aikaa, ei halua tehdä enää yhtäkään suurempaa työtä vailla versionhallinnan tuomaa turvaa ja apua. Se tuntuisi merkitsevän tarpeetonta riskinottoa, että mokaa jotain ja menettää tiedon, jonka olisi halunnut säilyttää, tai että kämmää jotain siirrellessään projekteja ympäriinsä työstäessään jotain useammassa eri paikassa...


kommentoi (viimeksi muutettu 27.06.2005 15:41)