Laiks versiju kontrolei: pirmās asinis
Jebkuram izstrādātājam ir skaidrs, ka versiju kontroles sistēma ir jālieto. Gan tad, kad strādā viens, gan tad, kad strādā mazā kolektīviņā, gan tad, kad strādā pie maziem projektiņiem. Ja Tev tā nešķiet, tālāk vari nelasīt un komentāru formu vari lieki nesmērēt. Arī to, ka klasiskās VCS (SVN, CVS [rly?]) ir gana jaukas, lūdzu, neminam, jo visiem skaidri zināms, ka patiesība ir DVCS pusē.
Vienīgais sakarīgais iemesls, kuru es varētu pieņemt kā ieganstu (D)VCS nelietošanai, ir slinkums. Tas ir cilvēcīgi saprotami :)
Es par savām vajadzībām izcilu esmu atzinis Git. Neba nu citas ir sliktākas. Piemēram, Mercurial vairākos aspektos ar lietām tiek galā labāk nekā Git. Esmu dzirdējis arī par Darcs un Bazaar, tomēr esmu lepns Git lietotājs. Jāpiebilst, ka par labu šai izvēlei savu lomu ir nospēlējis arī GitHub projekts.
Vēlētos piespiest sevi uzrakstīt rakstu sēriju, kurā saviem vārdiem mazliet apskaidrot - kas un kā. Pasmelties idejas un pieredzi no jums. Tāpēc arī rakstu. Un sākšu ar pamatu. Tiem, kas labprāt lasa angliski un steidzās, nāksies meklēt citur. Piemēram, lasot grāmatas internetos. Viena no visieteicamākajām grāmatām ir “Pro Git”. Protams, ka nebūt ne slikta ir tautas rakstītā grāmatiņa: “Git Community Book”. Pieminēšanas vērts ir arī projekts “Git Magic”, kas ir ieturēts mazliet ... savādākā stilā. Protams, ka atceramies “Git Reference”. Jo sevišķi dēļ viegli atminamās adreses (gitref.org) un saprātīga vizuālā noformējuma.
Git ir sadalīta (distributed) versiju kontroles sistēma. Tai nav nepieciešams serveris. Tas nozīmē, ka jebkurš var uzinstalēt atbilstošu programmu, un sākt veidot un kontrolēt savas versijas. Momentā. Papildus tam, vēlētos piebilst, ka parasti Git mācās divos piegājienos. Pirmais - pamatfunkcionalitāte, kura piemīt jekburai ierastajai versiju kontroles sistēmai. Tas ir vienkārši saprotams un apgūstams. Nākamais jau ir tas, kur ir Git (jā, arī citu (D)VCS, trolli!) lielais spēks. Pats fundamentu fundaments: zarošana (branches), pati distributed komponente, indekss jeb staging area, utt.
Bet, pirms sākt, vajadzētu iepazīties ar galvenajiem konceptiem. Jā, zinu, ka tas ir pilnīgs bōrings, un dajoš mums reāli noderīgu un praksē pielietojamu infu, taču, taču pacietību, lūdzu. Viss būs.
Repository. Latviskojot sanāk kaut kas līdzīgs “glabātavai” vai “krātuvei”. Vai “kapličai”. Krātuve (izvēlējos šo) ir vieta, kurā satiekas visi tavi komiti (no commit, kas, diemžēl, tulkojas kā nodevums:). Git neglabā neiedomājamu skaitu modificēto failu versijas, bet gan tikai izmaiņas. Un, atšķirībā no CVS, tas visu glabā vienā vietā, nevis katrā apakšdirektorijā veidojot kaut ko savu. Krātuve satur, protams, arī metadatus, kas ietver sevī zarus (branches) un birkas (tags), kā arī vēl visvisādu informāciju, kas pašlaik varbūt pat nav tik dikti būtiska.
Commit (sauksim to par komitu; ejiet ieskrieties, pūristi). Versiju kontroles sistēmas pamatu pamats. Bez komita nebūtu versiju un nebūtu kontroles. Komits Git izpratnē ir versiju kontrolē iekļauto failu stāvoklis konkrētajā brīdī. Tas ir kā daudziem tik ļoti ierastās mapes manalapa.2011.07.01 un manalapa.2010.01.01. Taču, kā jau minēju, neaizņem tik daudz vietas, jo Git saglabā tikai izmaiņas kopš iepriekšējā reģistrētā stāvokļa (komita). Lai arī gribētos domāt, ka jebkurš iepriekšējais komits norāda uz nākamo, patiesībā ir otrādāk. Jebkurš nākamais komits norāda uz vienu vai vairākiem iepriekšējiem. Tā ir būtiska nianse, kas jāzin.
Working tree (darba versija?) ir tā augstākā līmeņa direktorija, ar kuru ir saistīta krātuve. Piemēram, ja mēs kontrolējam versijas iekš /var/www/manalapa, tad tā arī ir darba versija. Darba nozīmē, ka ar šo direktoriju mēs fiziski strādājam.
Staging area jeb indekss ir vieta, kur nonāk izmaiņas pēc to rašanās, bet pirms komitēšanas. Šis ir koncepts, kurš nepastāv ierastajās VCS. Ideja ir tāda, ka jebkurš komits ņem izmaiņas no staging area. Tas nozīmē, ka ir iespējama daudz detalizētāka kontrole pār to, kas tiek komitots. To var salīdzināt ar izmaiņu apstiprināšanu, pirms komitošanas - lai izmaiņas apstiprinātu, ir jāizmanto koamnda git add. No šī var izvairīties ar git commit -a, taču tas nāks vēlāk. Starp citu, ToirtoiseGit sekmīgi slēpj staging area koncepciju aiz savas vienkāršības.
Branch jeb atzars. Lai arī citās versiju kontroles sistēmās šī padarīšana ir pastāvējusi, tieši Git to ir izvedis, ja tā var izteikties, tautās, jo pārslēgšanša starp atzariem pat lieliem projektiem notiek ātri (jā, es vakar paprovēju nosvičot branču 2GB+ SVN projektam...). Atzari ir DVCS izstrādes cikla pašā pamatā. Ar šo Git principā vienpersoniski nogalināja visas tradicionālās VCS. Tīri tehniski atzars ir primitīva norāde uz kādu no komitiem. Teorijā, savukārt, viss ir daudz smalkāk. Atzari palīdz paralēli uzturēt neierobežotu skaitu versiju - izstrādes versija, produkcijas versija, ūber-fīča-X. Tie visi ir atzari, kas savā starpā var tikt apvienoti pilnīgi vai daļēji.
Tag jeb birka. Komitam piekabināms nosaukums. Piemēram, v1.0 :)
HEAD. Tā ir norāde uz faktisko izčekoto komitu vai atzaru. Izčekot komitu vai atzaru mēs varam mūsdienīgi aprakstīt kā “Klau, zini, kā man vakar izskatījās kods? Izčekosim un iečekosim, ne?”. HEAD vienmēr norādīs uz to, ar ko tiek strādāts no vēstures viedokļa. Par izčekošanu vēlāk, protams.
Šķiet, ka ar šo vajadzētu pietikt. Daudzi (ja ne visi) lielie palagi par Git sāk ar failu uzbūves, iekšējo struktūru un cita krepa aprakstīšanu, kas visus pamatā arī atbaida. Es centīšos no tā izvairīties, bet augstāk uzskaitītie koncepti tik tiešām ir fundamentāli nepieciešami.
Tā kā es nepretendēju uz 100% pareizību, jo neesmu nekāds guru, tad labojumi gaidāmi komentāros. Neprecizitātes ierakstā apsolos labot ar atsaucēm uz komentāriem. Tas pats attiecas uz izmantotajiem latviskojumiem - ja tev ir svaiga ideja, kas ģeldēs, dod ziņu. Pēc gada tiksimies otrajā sērijas ierakstā :)
2011. gada 12. augustā, plkst. 20:09
Pēc kāda gada? Lai nākamajā piektdienā būtu! :)
2011. gada 12. augustā, plkst. 20:41
Nesen ir parādījusies vēl viena DVCS Veracity (http://veracity-scm.com) un šodien tās autors Eric Sink pareklamēja, ka par brīvu izdala savu jaunās grāmatas "Version Control by Example" papīra versiju. Cik nu pašķirstīju pdf versiju, tad tur ir feini aprakstīti versiju kontroles pamati ar piemēriem Subversion, git, Mercurial un Veracity. Ja nu vēl kādam angliski lasošajam ir interese: http://www.ericsink.com/entries/vcbe_print_edition_free.html
2011. gada 12. augustā, plkst. 21:55
Kas tiešām uzrunā iekš Git ir Stash koncepts. Būtu interesanti palasīt tavu versiju par procesu kā jānotiek pārejai no dev uz production VCS kontekstā.
2011. gada 12. augustā, plkst. 22:10
!ob, stash ir parocīgi, tiesa. A deployments ir atkarīgs no milzuma daudz momentiem - projekta apmēra, kontributoru skaita (vai vispār - tādu esamības), piegāžu legalizācijas procesa (100% demokrātija vai kas sarežģītāks), testa/produkcijas/staging vides esamība, , utt. Mana versija, protams, arī būs.
2011. gada 12. augustā, plkst. 23:30
Es lasīju, lasīju, gandrīz aizmigu, un sapratu, tas tāpēc, ka nesaprotu, par ko vispār ir runa.
I like turtles!
2011. gada 12. augustā, plkst. 23:35
Tas, ka git nav nepieciešamas serveris, nenāk no fakta, ka tā ir sadalīta versiju kontroles sistēma. SVN'am arī nevajag serveri - klients var operēt ar repozitoriju ar file:// protokolu. Tas viss arī notiek momentā.
2011. gada 13. augustā, plkst. 12:32
Pirms kada laika pārgājam no SVN uz GIT. Prieks un bauda. Protams nedaudz pagāja laiks aprast ar nedaudz citiem principiem. Taču tagad viss ir labi. Vienīgi TortoiseGIT gan bija būt šausmīgi lēna caur Sambu (šķiet visi faili vienmēr iet vēl caur kompja tempu), tādēļ lietojam tikai konsoles variantu. SVNam šausmīgi besīja tie .svn katrā mapē, bieži kautko kopējot no projekta uz projektu regulari aizmirsās, ka tā darīt nav labi un bija regulāri gļuki. Arī GIT hooki ir baigi ērtie (uz svn nelietojām), var slēgt repositārijus visādās ķēdītēs utt...
2011. gada 13. augustā, plkst. 12:36
Bubu, es speciāli tagad nomigrēšu vienu 2+GB SVNu uz Git'u, un paprovēšu abos pačekautot.
2011. gada 13. augustā, plkst. 14:09
Vārds momentā bija ņemts no šī konteksta: "Tas nozīmē, ka jebkurš var uzinstalēt atbilstošu programmu, un sākt veidot un kontrolēt savas versijas. Momentā." SVN'am arī tiesi tāpat var uzinstalēt un sākt. Momentā. Par 2GB čekoutu - tā ir cita runa.
2011. gada 13. augustā, plkst. 14:18
bubu, ok. Bet ir mazliet sarežģītāk, tomēr. Jāveido atsevišķu repo ar <tt>svnadmin</tt>, kamēr git'am viss notiek ar <tt>git init .</tt>. Bet piekrītu, var arī sākt lokāli.
2011. gada 13. augustā, plkst. 21:12
Mēs pirms kāda laika nomigrējām no SVN uz Git. Nu ko lai saka, sākumā GIT likās parmērīgi samudrīts - bet nu kādu laiku palietojot liekas dikti labāk. Pārslēgšanās starp brančiem ir ļoti forša, daudz žiglāk kā svn gadienā.
2011. gada 14. augustā, plkst. 14:35
Paldies @Teloah par linku uz Eric Sink grāmatu.
2011. gada 15. augustā, plkst. 01:23
Jā, es arī daudz esmu dzirdējis par to, ka DVCS ir "nākamā paaudze" pēc CVCS (aka SVN un līdzīgie), bet nekad neesmu īsti sapratis - kur tad īsti ir tā sāls. Vienīgais, ko esmu sapratis, ir tas, ka tur kaut kā mānīgāk realizēta merdžošana (ņemot vērā zarošanās ķēdīti), kā rezultātā konflikti labāk atrisinās. SVN to solās ieviest nākamajās versijās.
Pamēģināju reiz palietot Mercurial ar TortoiseHg, bet pēc perfekti nostrādātā TortoiseSVN atbaidīja TortoiseHg zaļums. Un, protams, vienlietotāja režīmā mikroskopiskam projektiņam arī neizdevās izbaudīt ne 1% no labajām lietām. Tāpēc pagaidām vēl dzīvoju uz SVN ar Tortoizi - nav, par ko sūdzēties.
Taču interese ir - par ko tad visi tā sajūsmināti?
2011. gada 15. augustā, plkst. 09:18
Uz win gits joprojām ir jāgriež caur cygwin? Ja jā, tad vēl ilgi šis pasākums neiegūs popularitāti uz win platformām.
2011. gada 15. augustā, plkst. 09:41
Jo, sen jau vairs ne.
2011. gada 15. augustā, plkst. 11:40
Iespaidojoties no taviem rakstiem, esmu sācis lietot vcs, konkrēti - Git. Labs verķis! Toties vienīgais, kas ir jēdzīgs iekš TortoiseGit - tas ir help-s, kur apskaidrotas pamata lietas par Git.
2011. gada 15. augustā, plkst. 17:00
Kas tiek izmantots git instalācijai, msysgit? Incanti būtu uzzināt, kas tas ir par projektu, kuram source ir 2GB+
2011. gada 16. augustā, plkst. 15:51
Lai arī strādāju viens, beidzot esmu sācis lietot versiju kontroli. Kaut vai tādēļ, lai bez problēmām varētu sinhronizēt projektus starp dažādām darba stacijām, jo nākas strādāt gan birojā, gan mājās. Šobrīd spēlējos ar SVN. Kaut kur (neatceros, gan kur) biju lasījies, ka SVN ļauj vairākiem vienlaicīgi strādāt ar vienu un to pašu failu, bet komitojot bļauj par neatbilstībām, ja kāds komitojis pirms Tevis, rezultātā neļaujot visu sačakarēt. Tas ļauj izvairīties no situācijām, ja kāds nolokojis failu rediģēšanai un, piemēram, devies atvaļinājumā - līdz ar to, pārējie var sēdēt un gaidīt, kamēr šis būs atpakaļ. Sapratu, ka GIT turpretī ir failu lokošanas princips. Iepriekšējā darbā izmantojām Visual Studio Team System. Komandas sastāvs bija mainīgs un konstanti bija jāskraida pie admina, lai dod pieeju failiem, ko ižcekojuši iepriekšējie, kas projektā vairs nav iesaistīti un aizmigrējuši sazin kur. Vārdu sakot, bija čakars. Kāds viedoklis par šo?
2011. gada 16. augustā, plkst. 16:27
Man pagaidām lielākā aizķeršanās ir neizpratnē, kā vairāki cilvēki var savā starpā sadarboties, neizmantojot GitHub. Attiecīgi, ar SVN ir viss skaidrs - centrāls repozitārijs, caur kuru arī džeki strādā.
Liels pluss būtu rakstam, kas vienkāršā valodā aprakstītu kopainu, piemēram, lokālā tīklā organizēt sadarbību starp kodieriem, sinhronizēties ar izstrādi mājās (reāls darba piemērs). Lai arī cik ir izkliedēts repozitārijs, ir nepieciešama kaut kāda vieta, kur viemēr būs pieejama, piemēram, aktuālā produkcijas versija.
Vai arī DVCS gadījumā smadzene jāieloka citā formā?
2011. gada 16. augustā, plkst. 16:46
micro, kolaborācijas metodes apraksts arī ir plānā.
2011. gada 16. augustā, plkst. 17:09
Super! :)
2011. gada 16. augustā, plkst. 17:32
bfj - Jūs izmantojāt TFS vai Source Safe? Pirmais supportē (un pēc defaulta arī izmanto) SVN-stila nelokošanas metodes. Source Safe savukārt locko failus pēc defaulta, kas tiešām ir galvassāpes, un šādu variantu mūsdienās neviens prātīgs cilvēks neizmanto.
Jā, tiešām, SVN seko līdzi, kas kad ko ir mainījis, un, ja divi cilvēki reizē ir vienu un to pašu labojuši, tad ļauj Tev pašam izdomāt, kā apvienot visas izmaiņas. Šajā ziņā varu rekomendēt perfektu tūli vārdā Beyond Compare, kuru var integrēt ar TortoiseSVN, un kurš ir ar kārtu labāks, nekā Tortoise iebūvētais rīks. Taču lielākajā daļā gadījumu cilvēki neaiztiek vienas un tās pašas rindiņas, un SVN pats māk automātiski izdomāt, kā apvienot jūsu darbu, un Tu par to nemaz neuzzini.
2011. gada 16. augustā, plkst. 22:00
Un atkal skrienam pakaļ kaut kādām modes tendencēm. Rakstā ne vārdiņa par to, kas un kādām vajadzībām izveidoja Git.
DVCS ir vajadzīgs lielajiem open-source projektiem, kur strādā simtiem / tūkstošiem izstrādātāju un kur brānču taisīšana ir ļoti aktuāla - visi nedrīkst kommitēt vienā trunk'ā, izmaiņas vispirms ir jāizskata un jāakceptē projekta pārraugiem.
Savukārt salīdzinoši mazos proejktos (teiksim 10 koderi vai mazāk) šāda infrastruktūra nav vajadzīga. Brānču ir maz, un nav jānozīmē pārraugs, kas atbild par izmaiņu likšanu trunk'ā. Visi programmētāji drīkst kommitēt izmaiņas trunk'ā. Ja kāds salauž trunk'u, par to arī pats atbild. Šādi strādājot galvenā atšķirība starp VCS ir rīku atbalsts. Tam arī jābūt galvenajam kritērijam VCS izvēlē.
Ja brānču ir daudz, tad jāsecina, ka eksistē problēmas ar darba organizāciju. Neticu, ka autors piedalās Linux kerneļa izstrādē vai kādā citā lielā open-source projektā. Teksti no sērijas "jo visiem skaidri zināms, ka patiesība ir DVCS pusē" ir tukšs fleims.
2011. gada 16. augustā, plkst. 22:22
Vai tas, ka DVCS ir piemēros milzīgiem projektiem, nozīmē, ka tas nav piemērots vidējiem un maziem projektiem?
2011. gada 16. augustā, plkst. 22:38
Nē. Tas nozīmē, ka salīdzinoši mazos projektos neizpaužas DVCS priekšrocības. Kā jau minēju - mazos projektos galvenā atšķirība starp VCS ir rīku atbalsts.
2011. gada 17. augustā, plkst. 07:12
Raimonds,
2011. gada 17. augustā, plkst. 08:56
Paga, paga, kungi.
Raimond, kāpēc daudz branchi ir slikti? Feature branchi, hotfix branchi, utt - tas, manuprāt, padara visu procesu daudz pārskatāmāku un saprotamāku. Un tie ir ļoti parocīgi pat tik niecīgā komandā, cik vien niecīga var būt komanda ar trīs izstrādātājiem.
krikuli, savukārt Tev norādīšu, ka nav tā, ka katram devam ir savs māsters. Katrs devs strādā ar development branču, no kura atvasina savus feature vai hotfix brančus. Pie katras izdevības šī branča izmaiņas tiek pullotas no origin/development.
2011. gada 17. augustā, plkst. 10:21
Jā, pirms dažām nedēļām arī pārgājām uz Git. Sākumā bija diezgan grūti 'iebraukt', bet tagad jau +/- ir okej! :)
Gaidu otro daļu rakstam ar nepacietību. Interesanti arī kādreiz ko tādu palasīt dzimtajā valodā. :D
2011. gada 17. augustā, plkst. 10:38
Lai varbūt mazliet paskaidrotu Raimondam Laacz'a u.c. viedokļus par DVCS mazos projektos:
Cik es saprotu (bet es vēl pats daudz nesaprotu, tāpēc ar nepacietību gaidu nākamās raksta daļas), tad DVCS ir pilnīgi cita pieeja lietām, pilnīgi cits workflow. Ja SVN'ā brančus taisa reti (principā pa versijām vai uz lieliem ahead zariem), tad DVCS brančošana un merdžošana ir ikdienas lieta un vispārējā darba procesa sastāvdaļa. Tāpat kā, teiksim, komiti vai vēstures skatīšanās. Taču, tā kā tas viss notiek tikai uz Tava datora, tad neviens cits par Taviem privātajiem brančiem nemaz neuzzina. Tu tos lieto savai ērtībai. Ķeries pie kaut kā jauna - hops, mini-ahead-zariņš, uztaisi, iemerdžo atpakaļ, iznīcini zariņu. Ja pa to laiku vajag bugu palabot, pieslēdzies atpakaļ trunkam. Utt. Bet par to vairāk pats laacz. Kā jau teicu, es arī vēl līdz galam neizprotu šo workflow, tāpēc ceru, ka laacz pastāstīs par to vairāk.
Rezumē trīs vārdos - DVCS ir pilnīgi cita domāšana nekā CVCS, un brančošana/merdžošana tur ir normāla ikdienas sastāvdaļa.
2011. gada 17. augustā, plkst. 12:28
Par workflow laacz kādreiz jau ierūca http://laacz.lv/2010/11/22/git-branci/
krikulis: nepamanīju, kuras koncepcijas ir izslēdzošas? SVN arī taisa featūras branču un komito katru izmaiņu, sanesalauž buildu un svn merge reintegrate
2011. gada 17. augustā, plkst. 15:25
krikulis Nekā izslēdzoša tur nav. Kommitē tad, kad kaut kas ir pabeigts. Kaut vai reizi 3 dienās, nevis reizi 10 minūtēs, kad izlabota viena CSS rindiņa. Ja nu tomēr 3 dienās nevar pabeigt un izmaiņas traucēs citiem, tad taisa brānču. Prakse gan rāda, ka šādas situācijas ir reti.
Protams, ka ar trunk'a kodu testiem ir jāpildās un build serverim jāvar nokompilēt projektu. Bet ne jau 100% kommitu. Ja arī kaut kas ir salūzis, kommitu veikušais koderis kļūmi maksimāli īsā laikā novērš, un kļūme nevienam netraucē.
Vilx Protams, ka DVCS ir domāts citiem darba organizācijas principiem. Principiem, kurus lieto lielajos megaprojektos, bet kuri mazajos projektos ir visnotaļ bezjēdzīgi. Nu nav katram koderim savs brānčs vajadzīgs. Lieks haoss un integrācijas problēmas izstrādes procesā. Versiju kontrole kļūst par līmeni sarežģītāka - DVCS ir N koderu brānči un trunk's, bet klasiskajā VCS ir tikai trunk's (un iespējams, ka daži brānči).
Piemērs integrācijas problēmai - koderim Jānim un koderim Pēterim katram ir savs brānčs. Abi 5 dienas taisa katrs savu darba uzdevumu un pēc tām 5 dienām izmaiņas abi liek iekšā trunk'ā. Rezultāts - konflikts, jo Jānis pirmajā darba dienā bija pamainījis kaut kādas datu struktūras vai jebko citu, kas visu turpmāko Pētera darbu padara nelietojamu. Jānim šīs izmaiņas gan nešķita tik nozīmīgas, tādēļ viņš tās savlaicīgi neielika trunk'ā. Ja abi būtu strādājuši tikai ar trunk'u, šāda situācija nebūtu radusies. Varētu arī no brānča likt savas izmaiņas trunk'ā reizi dienā, taču tad tas būtībā vairs nav DVCS, bet gan klasiskais VCS.
2011. gada 18. augustā, plkst. 00:33
Arī klasiskajā SVN, ja Tu 5 dienas pie kaut kā viena strādā, tad diezi vai šajā laikā ik pa brīdim taisīsi Update. Rezultāts tāds pats. Pie tam - ja ir tikai Jānis un Pēteris, tad viņi ļoti labi zinās, kas ko taisa, un viens otram uz pirkstiem nekāps.
Šī ir fundamentāla problēma visā merdžošanas idejā (t.sk. failu nelokošanai) - Tu nekad nevari būt drošs par to, ka divi cilvēki neuzrakstīs kaut ko fundamentāli nesavietojamu. Vienīgais variants - lockot failus. Tikai tā var nonākt pie deadlockiem. Atkal štruntīgi. Par laimi pieredze rāda, ka praksē šādi gadījumi ir ārkārtīgi reti, un praktiski vienmēr ir iespējams normāli samerdžot visu. Jā, DVCS paļaujas uz šo sakritību. Bet... kā redzi, tas strādā. :)
Es neredzu šeit kaut kādus principus, kas būtu piemēroti tikai lielajiem projektiem, un ne mazajiem. Manuprāt, savs brančs katram developerim ir pavisam eleganti pielietojams paņēmiens arī miniprojektos. Varbūt viena cilvēka projektos tad vispār nevajag source kontroli? :)
2011. gada 18. augustā, plkst. 01:49
Par mērdžošanu - jo biežāk notiek sinhronizēšanās ar trunk'u, jo mazāka iespēja iegūt konfliktu. Ja strādā tikai ar trunk'u, tad update no trunk'a ir jāveic regulāri (teiksim katru reizi pieķeroties darbam) un arī regulāri ir jāseko līdzi tam, ko dara kolēģi. Savā ziņā komandas iekšējās kontroles mehānisms, un izstrādes vadītājam mazāk darba integrācijas problēmu risināšanā. Savukārt, ja katrs koderis ieraujas savā brānčā un neseko līdzi citu aktivitātēm, tad koda konflikti ir neizbēgami. Vispār gan ar vārdu "konflikts" es savā piemērā biju domājis plašāku jēdzienu - ne tikai mērdžošanas konflikts, bet arī jebkāds funkcionāls konflikts, izpildes laika kļūdas utt.
"Es neredzu šeit kaut kādus principus, kas būtu piemēroti tikai lielajiem projektiem, un ne mazajiem" Kā var neredzēt fundamentālu atšķirību starp vairāku līmeņu kommitiem (DVCS) un viena līmeņa kommitiem (klasiskais VCS)? Es turos pie principa, ka darba procesam ir jābūt pēc iespējas vienkāršākam. Un jā - ir gadījumi, kad viena cilvēka projektos versiju kontrole nemaz nav nepieciešama. Protams, eksistē indivīdi, kam patīk ar lielgabalu zvirbuļus šķaidīt...
2011. gada 18. augustā, plkst. 09:29
git "sāls" ir tajā, ka reālā koderu ikdiena ir sasteigtas lietas, haoss un spiediens "no augšas". un to visu var eleganti realizēt ar viņu ātro brančošanu un merdžiem ;)
piemērs iz dzīves: nedēļu tiek tapināta "LIELĀ LIETA", kura tiks bliezta iekšā kā 1 liels komits. jo. uz production servera ir SVN(uz kuru tiek komitots ar git-svn), attiecīgi, ja kaut kas nobrūk un prod. tomēr neceļās, tad 1 rollback izņem visu laukā un gatavs. bet. uzzīmējās cilvēks X un saka - man, cālīt, vajag to un šito ASAP izdarīt. tu iekomitē savas izmaiņas SAVĀ lokālajā brenčā "development", uztaisi update savam master brančam(no servera), no tā izveido jaunu branču "lotiatrivajagsito", tur iztaisi savas izmaiņas un iekomitē no branča uz production vai arī iemerdžo to brenču iekš master un taisi komitu no turienes. tātad, kur cundurs(prikols)? pēc asap lietas izdarīšanas, čeko ārā savu "LIELO LIETU" un turpini strādāt, pasaule nav beigusies :)
2011. gada 18. augustā, plkst. 13:34
Principā SVN uz 1.8 relīzi (plānots uz Q1 2012) ir paredzētas tādas lietas kā shelving un checkpointing, kas arī šīs problēmas risinātu. Taču tas vēl nav pienācis, kamēr DVCS to jau relatīvi eleganti atrisina.
Labi, gaidam laacz nākamās sērijas par workflowu, citādi es arī tikai no zila gaisa varu izraut spriedumus, knapi saprasdams, kā tas viss strādā.
2011. gada 18. augustā, plkst. 14:01
laacz, katram developerim ir savs masters, katrs lokāls git klons ir savs brančs
raimonds
nco, cik reāli un bieži izmantojat branchus SVNā ?2011. gada 18. augustā, plkst. 15:01
versiju kontrolei nav nekāda sakara ar projekta lielumu vai cilvēku daudzumu. Punkts.
Galu galā versiju kontroles pamatdoma ir versiju kontrole. Līdz ar to no kurienes rodas jautājums vai vajag viena cilvēka projektiem, vai vajag maziem projektiem? Protams ka vajag, jo versijas kontrolē neatkarīgi no cilvēku skaita. Vienam koderim arī ja kautkas saiet greizi vajag atgriezties pie iepriekšējās versijas vai atgriezt kautko no izmaiņām.
Vienkārši taisīt backupus ar strādājošām versijām ir jauki, bet... vai uztaisīt backup arhīvu ir ātrāk nekā komitoties? ne gluži. Vai atarhivēt backupu un mēģināt atcerēties un salīdzināt failus ir ātrāk nekā apskatīt historiju Git? pavisam noteikti nē.
protams ir jāatrod arī pareizie rīki lai tas būtu pietiekoši vienkārši. Es tagad sāku lietot egit uz eclipse .. nekādu problēmu un iespringšanas un vizuāli smuki.
2011. gada 18. augustā, plkst. 22:01
krikulis Brānčus lietoju reti. Standarta gadījumi:
"Līdz ar to no kurienes rodas jautājums vai vajag viena cilvēka projektiem, vai vajag maziem projektiem? " Rodas, liekot lietā veselo saprātu. Kāda x'a pēc piecu dienu projektam, kuram potenciāli būs pieci kommiti, taisīt versiju kontroli?
"vai uztaisīt backup arhīvu ir ātrāk nekā komitoties?" Jā, protams. Ikdienas šedulēts backup's visai darba mapei, kas uz backup folderi pārraksta tikai dienas izmaiņas. Lietoju gadiem (ar Robocopy). Failus backup'ā meklēt ir gadījies tikai dažas reizes.
2011. gada 19. augustā, plkst. 01:32
Raimonds:
iet runa nevis par ikdienas backupiem, bet par backupiem ar katru koda versiju lai nekas nepazuud un ir iespeeja atgriezt izmaiņas. Šajā gadījumā ir vieglāk kommitot nekā taisot tos bakupus.
ikdienas backupi ir jātaisa jebkurā gadījumā un to mērķis nav konkrētu izmaiņu atgriešana bet izvairīšanās no sirdstriekas kad nosprāgst hdd.
“Līdz ar to no kurienes rodas jautājums vai vajag viena cilvēka projektiem, vai vajag maziem projektiem? ” Rodas, liekot lietā veselo saprātu. Kāda x’a pēc piecu dienu projektam, kuram potenciāli būs pieci kommiti, taisīt versiju kontroli? "Un kāpēc nē? ja tie pieci komiti ir vajadzīgi tad kāpēc viņus netaisīt?" Git itkā nav ierobežojuma cik kommiti minimums, kautvai 2 pa visu dzīves laiku."
protams ja rīki nav atrasti pietiekami labi, tad tā visa padarīšana paņem vairāk laika/darba nekā nedarīšana. Bet ja īstie rīki ir pa rokai tad tas neprasa vairāk par 2 sekundēm lai uzsāktu projektu un 1 sekunde lai nospiestu kommit pogu un potenciāli var dot labumu.
Tas protams ir tikai mans viedoklis pēc savas situācijas. puslīdz izdevās savienot rīkus lai tas viss notiktu gandrīz automātiski un neprasītu nekādas īpašas darbības no manas puses. Līdz ar to tas ir ātrāk nekā uztaisīt projekta koda foldera kopiju
2011. gada 19. augustā, plkst. 10:59
Izlasīju, pusi sapratu, eju mācīties.
2011. gada 19. augustā, plkst. 12:12
par veiksmīgo brančošanas modeli - iesaku pačekot git-flow
2011. gada 19. augustā, plkst. 15:55
Četrdesmit otrais! :D
2011. gada 20. augustā, plkst. 00:40
Why Git is Better than X - http://whygitisbetterthanx.com/
2011. gada 20. augustā, plkst. 01:17
"Fanboyism, bandwagonism" :)
2011. gada 20. augustā, plkst. 14:26
Mees slondonas bankaa patreiz izturam ciinju par versiju kontroles serveriem. mums ir Perforce, CVS, SVN. Mees jau tresho reizi atgriezhamies pie SVN. Aatrums, tieshums, eertiiba visas iespeejamaas huinjas pavadaa. git ir vairaak *nix lietotaajiem. Visual Studio ir savaadaaks kraams. Git neiet cauri. :) Driikst C/C++ Win32 vergam izteikt viedokli shajaa saitaa sheit?
2011. gada 20. augustā, plkst. 14:33
Ja kaads nepiekriit - gaidu ciinjas laukaa SC2. Un tad vai nu es tikshu pazemots vai TU :D. Joks protams. :D
2011. gada 20. augustā, plkst. 14:35
Paldies Laacz, ka tev ir shaads saits. Es man liekas tavu win7 64 bit LV language update jau lietoju kaadu laiku.
2011. gada 22. augustā, plkst. 05:17
"Commit" nav, bet varētu būt "pienesums".