[voikko] Git- ja bzr-kokeilu

[Teemu Likonen]

Timo Jyrinki kirjoitti:

> 13.2.2008 Harri Pitkänen <hatapitk at iki.fi> kirjoitti:
> >  Tuttuus on varmasti svn:n paras puoli. Sitä osaavat käyttää (tai
> > ainakin oppivat nopeasti) lähes kaikki, jotka ovat koskaan
> > versionhallinnan kanssa olleet tekemisissä. Git on vähän
> > kummallisempi ja vaatii enemmän perehtymistä.
>
> Git:n varteenotettavana vaihtoehtona kannattaa harkita Bazaaria
> (bzr), josta olen kuullut paljon hyvää. Joku kuvaili sitä yhtä
> hyväksi (lähes) kuin git mutta paljon helppokäyttöisemmäksi.

Kiitos vinkistä. Olen nyt tutustunut gitin (1.5.3.7) lisäksi myös 
bzr:ään (1.1~rc1) sekä lueskellut postituslistoilta gitin ja bzr:n 
kehittäjien välisiä keskusteluja liittyen ohjelmistojen toimintaan.

Selvää ainakin on, että git on hieman aidommin hajautettu järjestelmä, 
ja sisäisesti se tuntuu toimivan kauniimmin. Tämän voi todentaa vaikka 
seuraavanlaisella esimerkillä.

Kaksi eri henkilöä, A ja B, luovat yhteisestä lähtökohdasta a oman 
haaransa. A tekee siihen muutoksen b ja B tekee muutoksen c. Muutokset 
b ja c ovat ristiriidassa keskenään eli niitä ei voi yhdistää ilman 
käsityötä.

 A   B

 a   a
 |   |
 b   c

Kun A yhdistää B:n haaran, tulee ilmoitus ristiriidasta, ja A ratkaisee 
sen käsin. Sen päätteeksi hän tekee merge-commitin m, jolloin A:n 
haarat näyttävät moniulotteisessa esityksessä (esim. gitk tai qgit) 
tältä:

   A

   a
  / \
 b   c
  \ /
   m

Sen jälkeen B yhdistää A:n haaran omaansa. Tässä git ja bzr eroavat 
toisistaan. Gitissä B saa automaattisesti A:n kanssa identtisen haaran, 
jossa ristiriita on ratkaistu ja haarat yhdistyvät nätisti. Sekä A:lla 
että B:llä lineaarinen versiohistoria (git log) näyttää samalta:

 A ja B

  a
  |
  b
  |
  c
  |
  m

Commitit ovat molemmilla samassa järjestyksessä ja niiden tunnukset ovat 
identtiset.

(Sivuhuomautus: Gitissä commit-tunnukset ovat SHA1-koodeja, 
esim. "f63b1d8b62ea72504f85e003817e67012ff7df3b". Sama tunnus 
tarkoittaa täsmälleen samaa commitia kaikkialla maailmassa, koska 
SHA1-koodin laskemiseen käytetään paitsi kyseisen commitin kaikkea 
tietoa mutta myös sitä edeltävän commitin koodia. Commit-tunnukset siis 
tavallaan sisältävät koko repositoryn siihenastisen historian.)

Sen sijaan bzr:ssä A ja B kumpikin tekevät oman merge-commitinsa ja 
kirjoittavat oman commit-viestinsä. B:n, joka yhdisti haarat 
jälkimmäisenä, ei onneksi kuitenkaan tarvitse enää ratkaista 
ristiriitaa. Hän näkee omassa versiohistoriassaan myös A:n tekemän 
merge-commitin (m1). B:n tekemä merge-commit (m2) ei siis oikeastaan 
sisällä muuta tietoa kuin vain B:n kirjoittaman viestin, että "tulipa 
tehtyä merge". Commitit ovat kummallakin eri järjestyksessä. Erot voisi 
kuvata näin:

  A     B

  a     a
  |     |
  b     c
  |     |
  c'    b'
  |     |
  m1    m1'
        |
        m2

Bzr numeroi commitit 1:stä eteenpäin numerojärjestyksessä, mutta 
toisesta haarasta yhdistetyt (') commitit saavat alanumeroita: 1.1.1, 
1.1.2 jne. Näitä numeroita ei voi käyttää universaalisti, koska eri 
haaroissa ne tarkoittavat eri asioita. Vain jos on jokin keskuspalvelin 
tai sovittu päähaara, niin sitä kautta voi ehkä viitata sen projektin 
sisällä revisionumeroilla. Se ei tietenkään ole enää hajautettu malli. 
Bzr:ssä on onneksi revision-id:t, jotka ovat yksilöllisiä ja ilmeisesti 
universaaleja. Ne täytyy erikseen kaivaa esiin esimerkiksi 
komennolla "bzr log --show-ids". Revision-id:t ovat 
muotoa "tlikonen at iki.fi-20080216213631-1gu7cf6f2ucsjxhk".

Tällä perusteella minusta git toimii kauniimmin varsinkin hajautetussa 
mallissa ja järjestelmän "sisäisen kauneuden" vuoksi yhtä lailla 
kauniisti myös keskitetyssä mallissa. Yhtenä syynä on se, että käytössä 
ovat aina pelkästään universaalit commit-tunnukset, ei mitään 
paikallisia, haarakohtaisia revisioita. Toinen syy on, että jos 
vaikkapa 10 hengen ryhmä tekee kehitystyötä ja ristiin rastiin yhdistää 
muutokset, niin gitissä kaikilla on lopulta identtinen lähdekoodipuu ja 
versiohistoria. Bzr:ssäkin tietysti lähdekoodipuu on kaikilla lopuksi 
identtinen, mutta versiohistoria on kaikilla hieman erilainen. Ero 
johtuu siitä, että jokainen joutuu tekemään oman merge-commitinsa 
siinäkin tapauksessa, että haarojen yhdistäminen sujuu vain lisäämällä 
uusia commiteja entisen perään (ns. fast-forward-tapaus).

Ohjelmien kehittäjien viestejä lukemalla selvisi, että bzr pitää 
alkuperäistä haaraa - ilmeisesti sitä, josta otetaan kopio - jotenkin 
ensisijaisena myös teknisessä mielessä. En oikein ole vielä ymmärtänyt, 
että millä tavalla. Gitin haarat ovat aidosti yhtä arvokkaita olivatpa 
ne sitten samassa repositoryssa tai vaikka eri puolilla maailmaa. Gitin 
versiohistoria (git log) ei erottele mitään "pää-commiteja" 
ja "haara-commiteja" vaan kaikki commitit ovat saman arvoisia 
riippumatta niiden alkuperästä (myös esim. sähköpostilla lähetetyt).

Käyttöliittymän kannalta bzr on hyvin lähellä svn:ää, eli svn:n jälkeen 
perusasiat oppii hetkessä. Gitin perusasioiden oppimiseen meni minulta 
pari päivää. Erityisesti haarat gitissä käsitellään ihan eri tavalla - 
tavalla, johon itse olen erityisen ihastunut. :)

Joka tapauksessa molemmat ovat erittäin päteviä järjestelmiä. 
Mercurialiin en ole tutustunut vielä lainkaan; joskus pitänee sekin 
katsastaa. Kiitokset Ville-Pekalle vinkistä.