logi sisse meist KKK
1
1

Harige rumalat. Ma pole siiani aru saanud, miks mul on vaja hajusat versioonikontrolli süsteemi (distributed version control system). Mõned põhjendused, mis ma olen kuulnud:

  1. Arendaja saab oma commitimata asju lokaalselt versioonida - minu arust saaks selle lahendada arendaja jaoks eraldi branchi tegemisega SVN-s. Branchi hoidmisega keskserveris on see eelis, et see tõenäoliselt backupitakse. Arendaja lokaalne repository võib koos läppari kõvakettaga õhku lennata või varastatakse lihtsalt läppar ära.
  2. Arendaja saab commitida offline olles, nt lennukis lennates - võib-olla USA-s on see tavaline, aga kui mina lähen kuhugi, kuhu lennukiga lendama peab, püüan ma arvuti tavaliselt maha jätta. Ja Eestis on ka rongis ja bussis nett olemas. Ja nende paari tunni jooksul ei jõuagi niipalju koodi kirjutada, et seda versioonima peaks.
  3. Kui Sul pole kesksesse repositorysse õigusi, siis pead oma muudatusi versioonima lokaalselt ja saatma patchi, nt avatud lähtekoodiga projektid - põhimõtteliselt on see ainuke hea põhjendus minu jaoks, aga see ei tähenda, et ma oma firmasiseseid projekte peaksin niimoodi hoidma.

(Keegi targem võiks minu anglitsismid ära tõlkida :)

küsitud Oct 28 '09 at 07:40

Tambet%20Matiisen's gravatar image

Tambet Matiisen ♦♦
77791125

edited Mar 10 '10 at 15:50

Rene%20Saarsoo's gravatar image

Rene Saarsoo ♦♦
1.1k101121


Esimese punkti juurde võiks tuua veel selle, et kuna on lokaalne versioneerimine, siis commitid ei võta aega ja neid saab väga tihti teha, ilma et workflow selle all kannataks. Ning hiljem saab lokaalsest repositoryst ainult kindla valiku kesksesse repositorysse commitida.

See annab võimaluse katsetada erinevaid lahendusi või muuta süsteemi suuremalt ilma, et peaks kuidagi eraldi tegema koopiat töötavast koodist. Ehk siis iga väikse muutuse korral (üks osa suurest muutusest näiteks) teha commit lokaalsesse repositorysse. Seega kaob oht, et kui midagi tuksi läheb, ei pea kogu asja rollbackima või kuhugi väga algusesse tagasi minema vaid saab kõike väga väikeste sammudega teha.

link

vastatud Oct 28 '09 at 10:50

Siim%20Viikman's gravatar image

Siim Viikman
362

1

Ctrl+S = commit? Pole paha.

(Oct 28 '09 at 10:58) Tambet Matiisen ♦♦

Esiteks tuleb hajusa versioonihalduse juures aru saada sellest, et sa ei jää ilma millestki, mida pakuvad tsentraliseeritud süsteemid. Sa võid luua samamoodi keskse repositooriumi, kuhu kõik saavad oma muudatusi üles lükata ning teiste muudatusi alla tõmmata. Erinevus on selles, et Subversioni puhul see ongi su ainuke valik.

Et ma peamiselt tunnen Giti, siis järgnevalt just Giti eelistest, mis võivad aga ei pruugi kehtida kõigile hajusatele versioonihaldustele...

Gitiga tulevad varukoopiad kauba peale kaasa. Sa ütlesid, et keskserveri eelis on see, et see tõenäoliselt backupitakse. Kuid hajusa süsteemi puhul polegi erilist vajadust mingit eraldi varundamist sisse viia, kuna varukoopia kesksest repositooriumist on nagunii iga arendaja masinas olemas. Ning nagu me teame, siis paljudes ettevõtetes Subversioni repositooriumi tõenäoliselt ei backupita.

Giti repositooriumi loomisega saab hakkama isegi sülelaps. Ütleme, et alustad väikse prototüübi loomist. Selle peale kulub ehk paar-kolm päeva. Nagu igasuguse koodi puhul nii oleks ka prototüübi puhul hea kasutada versioonihaldust, eriti kui sa tahaks proovida läbi erinevaid variante. Kuid kas sa viitsid selle väikse asja jaoks kesksesse serverisse uue repositooriumi luua? Või paluda serveri adminil see luua? Tõenäoliselt mitte. Hajutatud versioonihalduse puhul seda küsimust ei kerki - on ilmelihtne lüüa oma prototüübi kataloogis sisse käsk git init ning uus repositoorium ongi olemas, sealsamas kataloogis.

Git muudab igaveseks sinu ettekujutust sellest mida branchimine tähendab. Subversionis pead sa uue haru loomiseks tegema midagi sellist:

cd myproject
svn cp http:///myproject/trunk http:///myproject/branches/mybranch
cd ..
svn co http:///myproject/branches/mybranch
# ...oota mitu minutit...
cd mybranch

Gitiga käib branchimine nõnda:

cd myproject
git branch mybranch
git checkout mybranch  # ...toimub hetkeliselt...
# alusta tööd uue branchi kallal siinsamas kataloogis
# tee mitu committi, seejärel lülitu tagasi põhiharule
git checkout master # ...jällegi hetkeliselt...
# kogu su kataloogi sisu on nüüd selline nagu põhiharus

Seega Gitiga võid branchida mitu korda päevas, mitu korda tunnis, nii palju kui süda lustib. Ning branchide vahel lülitamine käib ülimugavalt.

Git saab ise aru, millised failid on ümber nimetatud, kopeeritud, kustutatud. Subversionile pead seda kõike aga ise konkreetselt ütlema. Näiteks nõnda:

svn mv Foo.c Bar.c
svn rm OldFoo.c
svn cp Template.c New.c
svn ci

Giti puhul sa lihtsalt kustutad, nimetad ümber ja kopeerid nii nagu sa normaalselt teeksid ja siis lihtsalt:

git add --all # juhul kui on tarvis uusi faile lisada
git ci -a
link

vastatud Oct 28 '09 at 20:12

Rene%20Saarsoo's gravatar image

Rene Saarsoo ♦♦
1.1k101121

edited Oct 28 '09 at 21:06

DVC eelis tekib just siis, kui tegemist on suurte projektidega. DVC võimaldab tekitada keerulisemaid skeeme kuidas nö. koodi läbivaadatakse (näiteks miks Linux GIT-i kasutab).

Samuti lokaalsed ja enda eksperiment branchid on väga sõltuvust tekitavad. (Vahel on olukordi kus on endal 7 või rohkem isiklikku branchi.)

Samuti tundub, et hg, git ja bz oma olemuselt 'branch merge'-mise paremini läbi mõelnud. Kuna seal on just soodustatud isiklikud ja eksperimentaalsed 'branch'-id, siis peab neid olema ka kerge kokku sobitada.

Mergemise headusest git-i näitel:

Ütleme, et mitu erinevat inimest töötavad ühe mingi projekti ja on mitu erinevat uut asjandust tulemas projekti. Igal featuuril on oma branchid

 git branch feature-a master
 git branch feature-b master
 git branch feature-c master
 git branch feature-d master

Siis sul on veel mingid fix branchid

 git branch fix-func-a master
 git branch fix-func-b master

Ning mingil hetkel, näiteks päeval lõpus... öeldakse, et feature-a ja feature-b, et nende kood üsnagi toimib. Selleks, et testida, kas nende kood koos töötab, ning kõike kokku proovida tuleb teha lihtsalt.

 git branch alpha master
 git co alpha
 git pull . feature-a feature-b fix-func-a fix-func-b

(parimal juhul ei tule käsitsi midagi merge-da, git teeb kõik ise... ainult sel juhul tuleb seda ise teha, kui kahes branchis on samu koodi ridu muudetud... loomulikult kaasneb automaatse merge-ga mõned ohud...)
nüüd kui kõik branch alpha on testitud:

git co master
git pull . alpha
git branch -d alpha feature-a feature-b fix-func-a fix-func-b

Selle lõpuks on sul olemas ainult branchid master, feature-c, feature-d. Loomulikult on olemas kogu history iga eelneva branchi kohta.

Midagi taolist toimub linux-kernel-i arendamisel. Kuna paljud arendavad oma osasid, siis tuleb sellist ühist mergemist päris palju. (26-branchi näiteks korraga mergeda).

link

vastatud Oct 28 '09 at 14:12

egon's gravatar image

egon ♦♦
771239

edited Oct 30 '09 at 14:34

Mul tekib kohe mure, et kui feature-a ja feature-b on üksikuna testitud, siis tuleks nad testida üle ka koos. Ja koos fix-func-a'ga jne. See on suur õnn, kui kood on nii hästi modulariseeritud, et muudatused üksteist ei mõjuta. Minu maailmas tavaliselt nii ei ole.

(Oct 29 '09 at 13:43) Tambet Matiisen ♦♦

Loomulikult ma saan aru, et alati see nii lihtne ei ole... Üldiselt ma ise ka sedaviisi ei tee... Aga, kui sa üldiselt tead, mis asju mingi feature/fix mõjutab siis nendel hetkedel on seda täiesti võimalik teha... samas peamiselt tõin selle näite sellepärast, et näidata, kui lihtsaks on see branchide majandamine DVCS-des tehtud... Võid vaadata näiteks http://www.youtube.com/watch?v=L2SED6sewRw - seal on sellest kuidas kerneli arendamine käib...

(Oct 30 '09 at 04:28) egon ♦♦

git-refactor? Minu Git sellist käsku küll ei toeta. Tahtsid öelda git-branch -d ?

(Oct 30 '09 at 08:02) Rene Saarsoo ♦♦

Ühe põhjuse võib siia kohe lisada: arendajad saavad omavahel koodi jagada, ilma et see peaks keskrepositooriumist läbi käima. Näiteks võib tegemist olla mõne eksperimendiga või lihtsalt sooviga lasta teisel kood üle vaadata.

Kui nüüd Sinu esimese põhjenduse juurde minna, siis on nii et kui tegemist on vähegi suurema projektiga (pean silmas koodi mahtu, arendusperioodi pikkust, tiimi suurust), siis mõte sellest, et iga arendaja teeb SVNi muudkui uus harusid endale ei tundugi korraga üldse nii hea enam.

Kõvaketta õhku lendamise või varastamise oht ju muidugi on, kuid sa ju ometi teed varukoopiad teistest olulitest asjadest, mis sul läpaka kõvakettal on? Seega võib lokaalse repositooriumi ka sinna varundatavate asjade hulka lisada ja see maandab kadumamineku riski kohe üsna olulisel määral.

Ja kui nüüd spetsiifilisemaks minna ja rääkida näiteks git-ist, siis lisaks sellele, et ta on hajussüsteem, annab ta juurde ka mõned võimalused, mis oma olemuselt ei ole üldse hajusad, aga mis SVNiga lihtsalt võimatud on - minu lemmik on näiteks see, et git jälgib "teksti", mitte faile. Kui refaktoorid oma koodi ühest failist teise, siis git teab kust see tulnud on. Ja see on teinekord üks äraütlemata kasulik teadmine.

link

vastatud Oct 28 '09 at 10:23

Anti%20Veeranna's gravatar image

Anti Veeranna
2063

Kui eesmärk on koodi jagamine omavahel, siis "ilma keskrepositooriumist läbikäimata" ei anna minu arust mingit sisulist eelist. Seda saaks samuti teha branchidega. Aga olen nõus, et SVN-s igale mehele branchide tegemise õiguse andmine ei pruugi skaleeruda väga suurte projektide jaoks. Aga väikeste ja keskmiste jaoks küll - võid ju SVN-i branches kataloogis teha iga arendaja jaoks oma alamkataloogi ning anda õigused ainult sinna. Tänud git-i teksti jälgimise featuuri mainimise eest, seda ma enne ei teadnud.

(Oct 28 '09 at 10:52) Tambet Matiisen ♦♦
Sinu vastus
lülita eelvaade

Jälgi seda küsimust

By Email:

Pärast sisselogimist saad tellida muudatuse teavitusi siit

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *kaldkiri* või __kaldkiri__
  • **paks kiri** või __paks kiri__
  • link:[tekst](http://url.com/ "pealkiri")
  • pilt?![alt tekst](/path/img.jpg "pealkiri")
  • nummerdatud nimekiri: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • põhilised HTML märgendid on samuti toetatud

Pinu tööpakkumised

kõik pakkumised »

Küsimuse sildid:

×3
×2
×1

küsitud: Oct 28 '09 at 07:40

nähtud: 3,086 korda

viimati uuendatud: Mar 10 '10 at 15:50

Litsents: Creative Commons Attribution License | Kontakt: info@pinu.ee