Bola vydan\u00e1 verzia projektu mergiraf 0.4, ktor\u00fd rozv\u00edja ovl\u00e1da\u010d pre Git s implement\u00e1ciou mo\u017enosti trojstrann\u00e9ho zl\u00fa\u010denia. Mergiraf podporuje rie\u0161enie r\u00f4znych typov konfliktov pri zl\u00fa\u010den\u00ed a m\u00f4\u017ee sa pou\u017e\u00edva\u0165 pre r\u00f4zne programovacie jazyky a form\u00e1ty s\u00faborov. Je mo\u017en\u00e9 ho vyu\u017ei\u0165 ako samostatn\u00fd pr\u00edkaz mergiraf na spracovanie konfliktov, ktor\u00e9 vznikaj\u00fa pri pr\u00e1ci s be\u017en\u00fdm Gitom, alebo ako n\u00e1hradu v Gite pre spracovate\u013eov zl\u00fa\u010denia, \u010d\u00edm sa roz\u0161iruj\u00fa mo\u017enosti pr\u00edkazov ako merge, revert, rebase a cherry-pick. K\u00f3d je distribuovan\u00fd pod licenciou GPLv3. V novej verzii bola pridan\u00e1 podpora jazykov Python, TOML, Scala a Typescript, ako aj optimaliz\u00e1cia v\u00fdkonu. <\/p>\n
Ni\u017e\u0161ie je podrobne pop\u00edsan\u00e9, ak\u00e9 probl\u00e9my sa daj\u00fa vyrie\u0161i\u0165 pomocou mergiraf: <\/p>\n
Softv\u00e9r je jasn\u00fdm pr\u00edkladom mimoriadne zlo\u017eit\u00e9ho syst\u00e9mu. Zlo\u017eit\u00e9 syst\u00e9my maj\u00fa jednu spolo\u010dn\u00fa vlastnos\u0165 \u2014 s\u00fa ZLO\u017dIT\u00c9 \u2014 a nem\u00f4\u017eete o\u010dak\u00e1va\u0165, \u017ee po\u017eadovan\u00e9 zlo\u017een\u00e9 spr\u00e1vanie sa objav\u00ed samo osebe, n\u00e1hodou. Namiesto toho sa tieto syst\u00e9my vyv\u00edjaj\u00fa v priebehu \u010dasu, krok za krokom, a ka\u017ed\u00e1 mut\u00e1cia je starostlivo overovan\u00e1 v ka\u017edej f\u00e1ze. Na dosiahnutie tohto cie\u013ea s\u00fa potrebn\u00e9 dobre definovan\u00e9 \u0161trukt\u00fary a vhodn\u00e9 n\u00e1stroje. V\u00fdvoj akejko\u013evek zlo\u017eitej s\u00fastavy je mo\u017en\u00e9 vizualizova\u0165 vo forme orientovan\u00e9ho stromu, kde kore\u0148 predstavuje pr\u00e1zdnu mno\u017einu funkci\u00ed a ka\u017ed\u00fd uzol \u2014 okrem kore\u0148a \u2014 je v\u00fdsledkom aplik\u00e1cie mut\u00e1cie na svojho rodi\u010da. <\/p>\n
V kontexte produktov sa ka\u017ed\u00fd uzol naz\u00fdva \u201everziou\u201c, ktor\u00e1 predstavuje konkr\u00e9tnu sadu funkci\u00ed a antifunkci\u00ed. Ak\u00e1ko\u013evek zmena tejto s\u00fapravy sa pova\u017euje za mut\u00e1ciu, ktor\u00e1 vytv\u00e1ra hranu v na\u0161om orientovanom acyklickom grafe. Tieto funkcie s\u00fa v podstate abstraktn\u00e9; priamo neodr\u00e1\u017eaj\u00fa sp\u00f4soby fungovania fyzick\u00fdch syst\u00e9mov, ale sk\u00f4r demon\u0161truj\u00fa, ako rozumn\u00ed agenti vn\u00edmaj\u00fa vyu\u017eitie t\u00fdchto syst\u00e9mov. Aby sa my\u0161lienky premenili na existuj\u00face implement\u00e1cie vo fyzickom svete, je potrebn\u00e9 vyhrn\u00fa\u0165 si ruk\u00e1vy a ponori\u0165 sa do *dos\u0165* n\u00edzko\u00farov\u0148ov\u00fdch detailov, v jazyku ktor\u00fdch m\u00f4\u017eeme vyjadri\u0165 a vysvetli\u0165, ako konkr\u00e9tne v\u0161etko funguje. V v\u00fdvoji softv\u00e9ru s\u00fa tieto n\u00edzko\u00farov\u0148ov\u00e9 zvy\u010dajne reprezentovan\u00e9 zdrojov\u00fdm k\u00f3dom. <\/p>\n
Aby postupne priviedli zdrojov\u00fd k\u00f3d do stavu, ktor\u00fd prejavuje po\u017eadovan\u00e9 spr\u00e1vanie, a zdokumentovali, ako tam pri\u0161li, program\u00e1tori prezentuj\u00fa svoju pr\u00e1cu v pojmoch snapshot-ov a changeset-ov. Snapshot predstavuje ur\u010dit\u00e9 stane produktu so v\u0161etk\u00fdmi n\u00edzko\u00farov\u0148ov\u00fdmi detailmi, zatia\u013e \u010do changeset ozna\u010duje prechod medzi snapshot-ami. Zvy\u010dajne sa snapshot-y vytv\u00e1raj\u00fa z jednotliv\u00fdch changeset-ov k ich rodi\u010dom, tak\u017ee tieto snapshot-y takmer v\u017edy ozna\u010duj\u00fa to, \u010do robia changeset-y, ktor\u00e9 ich vytvorili, a preto sa tieto pojmy \u010dasto pou\u017e\u00edvaj\u00fa zamenite\u013ene. <\/p>\n
Niekedy existuj\u00fa sn\u00edmky vytvoren\u00e9 v d\u00f4sledku nieko\u013ek\u00fdch prechodov \u2014 zl\u00fa\u010denia commitov. S nimi sa \u0165a\u017eko pracuje, preto sa im zvy\u010dajne vyh\u00fdbaj\u00fa. Modern\u00e9 syst\u00e9my spr\u00e1vy verzi\u00ed s otvoren\u00fdm zdrojov\u00fdm k\u00f3dom, ako napr\u00edklad Git, poskytuj\u00fa ve\u013emi z\u00e1kladn\u00e9 mo\u017enosti na riadenie pracovn\u00fdch procesov v\u00fdvoja. Umo\u017e\u0148uj\u00fa v\u00fdvoj\u00e1rom organizova\u0165 sn\u00edmky vo forme orientovan\u00fdch acyklick\u00fdch grafov, anotova\u0165 ich koment\u00e1rmi a pri potrebe meni\u0165 ich poradie. <\/p>\n
T\u00e1to funk\u010dnos\u0165 umo\u017e\u0148uje v\u00fdvoj\u00e1rom p\u00edsa\u0165 semanticky v\u00fdznamn\u00fd pr\u00edbeh projektu, \u010do je rozhoduj\u00face pre ladenie a odpovede na ot\u00e1zky ako \u201ePre\u010do bola zaveden\u00e1 t\u00e1to n\u00edzko\u00farov\u0148ov\u00e1 \u010das\u0165 (napr. premenn\u00e1)?\u201c, \u201eAk\u00e9 percento je pribli\u017ene m\u00f4j pr\u00edspevok do tohto projektu?\u201c, \u201eKedy bol hacknut\u00fd implant\u00e1t a kto to urobil?\u201c, \u201eAk\u00e1 n\u00edzko\u00farov\u0148ov\u00e1 zmena rozbila t\u00fato funkciu (aj ke\u010f to nevyzeralo, \u017ee by mala, v\u0161etko sme skontrolovali!?)\u201c <\/p>\n
Syst\u00e9my kontroly verzi\u00ed dop\u013a\u0148aj\u00fa t\u00fato konceptom vetvy \u2014 n\u00edzko\u00farov\u0148ov\u00fd pojem, ktor\u00fd znamen\u00e1 jednoducho nepretr\u017eit\u00fd fragment n\u00edzko\u00farov\u0148ovej hist\u00f3rie projektu, semanticky v\u00fdznamn\u00fd pre v\u00fdvoj\u00e1ra. Vetvy sa zvy\u010dajne pou\u017e\u00edvaj\u00fa pre konkr\u00e9tnu implement\u00e1ciu funkci\u00ed, niekedy sa vytv\u00e1ra nieko\u013eko vetiev pre r\u00f4znych kandid\u00e1tov na implement\u00e1ciu tej istej funkcie. Pou\u017eit\u00edm pracovn\u00fdch postupov s vetven\u00edm (\u010do s\u00fa v skuto\u010dnosti mainstream a \u0161tandard v\u00fdvoja, pou\u017e\u00edvan\u00e9 v\u0161ade a bez v\u00fdnimky) m\u00f4\u017ee ka\u017ed\u00fd jednotliv\u00fd v\u00fdvoj\u00e1r efekt\u00edvne spravova\u0165 mnoho konfliktuj\u00facich vetiev projektu, z ktor\u00fdch ka\u017ed\u00e1 sa l\u00ed\u0161i v stupni pripravenosti alebo kvalite. To umo\u017e\u0148uje v\u00fdvoj\u00e1rom kombinova\u0165 v\u00fdsledky svojich a cudz\u00edch pr\u00e1c bez toho, aby museli ru\u010dne prepisova\u0165 v\u0161etko zaka\u017ed\u00fdm. <\/p>\n
Vo v\u0161eobecnosti sa vytv\u00e1ra hlavn\u00e1 vetva, ktor\u00e1 predstavuje \u201eofici\u00e1lny\u201c produkt, od ktorej sa odde\u013euj\u00fa bo\u010dn\u00e9 vetvy pre ka\u017ed\u00fa funkciu, ktor\u00e9 sa pravidelne (ide\u00e1lne \u2014 po ka\u017edom commite) synchronizuj\u00fa s hlavnou vetvou, \u010do umo\u017e\u0148uje v\u00fdvoj\u00e1rom pracova\u0165 s najnov\u0161ou verziou produktu a z\u00e1rove\u0148 zav\u00e1dza\u0165 funkcie, ktor\u00e9 pr\u00e1ve vyv\u00edjaj\u00fa, detekuj\u00fac probl\u00e9my vypl\u00fdvaj\u00face z \u010dinnost\u00ed in\u00fdch v\u00fdvoj\u00e1rov \u010do najsk\u00f4r. <\/p>\n
Pri pokuse kombinovania funkci\u00ed r\u00f4znych snapshotov (\u010do je jednoducho n\u00e1jdenie spolo\u010dn\u00e9ho predka a aplik\u00e1cia changeset-ov, ktor\u00e9 ich vytv\u00e1raj\u00fa, postupne na in\u00fd, t\u00e1to oper\u00e1cia sa naz\u00fdva rebase, zl\u00fa\u010denie je takmer ako rebase, len \u0161trukt\u00faruje graf commitov inak, \u010do rob\u00ed manipul\u00e1ciu s nimi nepohodlnou, preto sa od zl\u00fa\u010den\u00ed up\u00fa\u0161\u0165a v prospech rebase-ov) vznikaj\u00fa probl\u00e9my. Modern\u00e9 syst\u00e9my na kontrolu verzi\u00ed (VCS) pou\u017e\u00edvaj\u00fa intern\u00e9 algoritmy na zl\u00fa\u010denie zmien, ktor\u00e9 jednoducho rozde\u013euj\u00fa s\u00fabory na jednotliv\u00e9 riadky, pova\u017euj\u00fa ka\u017ed\u00fd riadok za znak, a s\u00fabory za ich sekvencie, a n\u00e1sledne aplikuj\u00fa algoritmy na ich zl\u00fa\u010denie, ktor\u00e9 poch\u00e1dzaj\u00fa z bioinformatiky. <\/p>\n
Nane\u0161\u0165astie, tak\u00e1to po\u013en\u00e1 prezent\u00e1cia zdrojov\u00e9ho k\u00f3du nem\u00e1 ni\u010d spolo\u010dn\u00e9 s jeho obsahom. Jedinou jeho v\u00fdhodou je, \u017ee je jednoduch\u00e1 a univerz\u00e1lna. Rozpor vedie ku konfliktom, pri\u010dom je st\u00e1lym zdrojom bolesti hlavy pre v\u00fdvoj\u00e1rov. Rie\u0161enie konfliktov si od v\u00fdvoj\u00e1ra vy\u017eaduje d\u00f4kladn\u00e9 presk\u00famanie oboch verzi\u00ed k\u00f3du, pri\u010dom nie len \u010dast\u00ed, ozna\u010den\u00fdch algoritmom porovn\u00e1vania ako \u201ezmenen\u00e9\u201c alebo \u201ekonfliktn\u00e9\u201c, ale mo\u017eno aj cel\u00e9ho projektu. <\/p>\n
V\u00fdvoj\u00e1r mus\u00ed pochopi\u0165 zmeny, manu\u00e1lne nap\u00edsa\u0165 zl\u00fa\u010den\u00fd k\u00f3d a odstr\u00e1ni\u0165 ak\u00e9ko\u013evek nezrovnalosti. Probl\u00e9mov nar\u00e1stne, ke\u010f po\u013en\u00fd n\u00e1stroj nespr\u00e1vne identifikuje zmeny, \u010do sa \u010dasto st\u00e1va pri ve\u013ek\u00fdch zmen\u00e1ch, vr\u00e1tane trivi\u00e1lnych, ako je preformatovanie k\u00f3du. Ak sa nasleduj\u00face zmeny nedaj\u00fa aplikova\u0165 na manu\u00e1lne zl\u00fa\u010den\u00fd k\u00f3d, situ\u00e1cia sa premen\u00ed na \u00fapln\u00fd no\u010dn\u00fa moru. Napriek hrozn\u00fdm pr\u00edpadom, v mnoh\u00fdch pr\u00edpadoch po\u013en\u00fd algoritmus funguje, najm\u00e4 ak sa v\u00fdvoj\u00e1ri akt\u00edvne sna\u017eia nevytv\u00e1ra\u0165 mu probl\u00e9my. Jeden zo sp\u00f4sobov, ako minimalizova\u0165 podobn\u00e9 probl\u00e9my, je povinn\u00e9 spracovanie zdrojov n\u00e1strojmi kanonikaliz\u00e1cie, ako je black. <\/p>\n
Samozrejme, spr\u00e1vne rie\u0161enie stra\u0161n\u00fdch pr\u00edpadov (a vlastne nielen pre ne, riadkov\u00fd algoritmus \u2014 to je heuristika, m\u00f4\u017ee trivi\u00e1lnym sp\u00f4sobom vies\u0165 k nefunk\u010dn\u00e9mu k\u00f3du, napr\u00edklad jeden v\u00fdvoj\u00e1r premenoval premenn\u00fa, zatia\u013e \u010do druh\u00fd nap\u00edsal kus nov\u00e9ho k\u00f3du, ktor\u00fd pou\u017e\u00edva t\u00fato premenn\u00fa, konflikt zl\u00fa\u010denia\/reb\u00e1zovania sa tu nebude, ale v\u00fdsledok sa stane nefunk\u010dn\u00fdm) \u2014 je pou\u017eitie spr\u00e1vneho vn\u00fatorn\u00e9ho modelu. <\/p>\n
Napriek tomu, \u017ee v\u00fdskum v tejto oblasti sa uskuto\u010d\u0148uje u\u017e pribli\u017ene 30 rokov a vy\u00fastil do vytvorenia nieko\u013ek\u00fdch propriet\u00e1rnych komer\u010dn\u00fdch produktov, tieto v\u00fdskumy do ned\u00e1vna neboli premenen\u00e9 na prakticky vyu\u017eite\u013en\u00e9 produkty s otvoren\u00fdm zdrojov\u00fdm k\u00f3dom. Hlavn\u00e1 masa rie\u0161en\u00ed OSS za\u010dala vznikn\u00fa\u0165 za\u010diatkom desa\u0165ro\u010dia 2010 a bola zameran\u00e1 hlavne na jazyk Java. <\/p>\n
Najv\u00fdraznej\u0161ia vo\u013en\u00e1 implement\u00e1cia tej doby, GumTree, bola vytvoren\u00e1 v\u00fdskumn\u00edkom s akademick\u00fdm z\u00e1zem\u00edm, nap\u00edsan\u00e1 v Jave, m\u00e1 svoje abstraktn\u00e9 vn\u00fatorn\u00e9 zobrazenie predch\u00e1dzaj\u00face treesitter, m\u00e1 backendy postaven\u00e9 na treesitter ako aj na in\u00fdch n\u00e1strojoch na parsovanie zdrojov\u00e9ho k\u00f3du do abstraktn\u00fdch zobrazen\u00ed. Tento syst\u00e9m dok\u00e1\u017ee iba generova\u0165 (vo forme textov\u00e9ho logu udalost\u00ed, tie\u017e je k dispoz\u00edcii API, ktor\u00e9 je mo\u017en\u00e9 jednoducho vyvola\u0165 z ak\u00e9hoko\u013evek programovacieho jazyka, ktor\u00fd m\u00e1 viazanie na Java) a vizualizova\u0165 zmeny. Av\u0161ak pre zl\u00fa\u010denie zmien, ako aj pre prezeranie generovan\u00fdch diff s\u00faborov, je z v\u00fdroby nepou\u017eite\u013en\u00e1 (aj ke\u010f je pravdepodobn\u00e9, \u017ee na\u010d\u00edtanie diffov je mo\u017en\u00e9 realizova\u0165 prostredn\u00edctvom API). <\/p>\n
Mlad\u0161ia a praktickej\u0161ie pou\u017eite\u013en\u00e1 implement\u00e1cia difftastic je nap\u00edsan\u00e1 v Ruste, je zalo\u017een\u00e1 na treesitter a s\u00fastre\u010fuje sa na generovanie zv\u00fdraznen\u00fdch diffov v konzole. Tento syst\u00e9m je zameran\u00fd tie\u017e na vizualiz\u00e1ciu diffov a v\u00f4bec nem\u00e1 cie\u013e zl\u00fa\u010di\u0165 zmeny alebo aplikova\u0165 patche. <\/p>\n
Celkom ned\u00e1vno sa objavil a akt\u00edvne sa vyv\u00edja projekt mergiraf. Tento n\u00e1stroj nap\u00edsan\u00fd v Rust (zaber\u00e1 21 MiB!) je tie\u017e zalo\u017een\u00fd na treesitter, ktor\u00fd sa u\u017e stal rovnak\u00fdm \u0161tandardom pre parserov kontextovo vo\u013en\u00fdch gramat\u00edk v n\u00e1strojoch v\u00fdvoja, ak\u00fdm sa stal LLVM pre optimaliz\u00e1ciu n\u00edzko\u00farov\u0148ov\u00fdch reprezent\u00e1ci\u00ed in\u0161trukci\u00ed. Na rozdiel od konkurentov, mergiraf poskytuje funkcie nie na generovanie diff-ov, ale na automatick\u00e9 rie\u0161enie konfliktov zl\u00fa\u010denia. Pod kapotou mergiraf pou\u017e\u00edva na generovanie patchov implement\u00e1ciu algoritmu pou\u017eit\u00fa v GumTree, a na aplik\u00e1ciu \u2014 implement\u00e1ciu algoritmu pou\u017eit\u00fa v spork, prisp\u00f4soben\u00e9 pre \u0161trukt\u00fary treesitter. <\/p>\n
Serializ\u00e1cia patchov do s\u00faborov, ktor\u00e9 m\u00f4\u017eu by\u0165 nesk\u00f4r aplikovan\u00e9, bohu\u017eia\u013e nie je implementovan\u00e1 (ale je celkom pravdepodobn\u00e9, \u017ee by mohla by\u0165 realizovan\u00e1 parsingom logov udalost\u00ed generovan\u00fdch GumTree). In\u00fdm perspekt\u00edvnym sp\u00f4sobom aplik\u00e1cie rozdielov by mohlo by\u0165 pou\u017eitie rozdielov nie cez patche, ale cez funk\u010dnos\u0165 refaktoringu LSP serverov, \u010do by mohlo pom\u00f4c\u0165 pri detekcii konfliktov na \u00farovni cel\u00e9ho projektu. Vizualiz\u00e1cia je podporovan\u00e1 len pre konflikty. <\/p>\n
Pr\u00edklad pr\u00e1ce: spolo\u010dn\u00fd predok \u201ebase.py\u201c (odsadenie tabul\u00e1tormi, zbyto\u010dn\u00fd riadok na za\u010diatku) foo = 1 def main(): print(foo + 2 + 3) \u201ea.py\u201c (odsadenie st\u00e1le tabul\u00e1tormi, 2 zbyto\u010dn\u00e9 riadky na za\u010diatku namiesto jedn\u00e9ho, pre ladic\u00ed tisk bola pou\u017eit\u00e1 kni\u017enica icecream, pridan\u00e1 trieda \u201ebaz\u201c: from icecream import ic foo = 1 def main(): ic(foo + 2 + 3) class baz: def __init__(self): \u201e\u201e\u201ebaz\u201c\u201e\u201e \u201eb.py\u201c (premenn\u00e1 \u201efoo\u201c premenovan\u00e1 na \u201ebar\u201c, spracovan\u00e9 pomocou \u201eblack\u201c po zmen\u00e1ch, v\u00fdsledkom s\u00fa odsadenia \u2014 medzerami a zbyto\u010dn\u00e9 riadky vystrihnut\u00e9): bar = 1 def main(): print(bar + 2 + 3) Volanie .\\\/mergiraf merge .\\\/base.py .\\\/a.py .\\\/b.py -x a.py -y b.py -s base.py -o .\\\/res.py d\u00e1va nasleduj\u00faci v\u00fdsledok from icecream import ic bar = 1 def main(): ic(bar + 2 + 3) class baz: def __init__(self): \u201e\u201e\u201ebaz\u201c\u201e\u201e (pre ladic\u00ed tisk bola pou\u017eit\u00e1 kni\u017enica \u201eicecream\u201c, premenn\u00e1 \u201efoo\u201c premenovan\u00e1 na \u201ebar\u201c, spracovan\u00e9 pomocou \u201eblack\u201c po zmen\u00e1ch, v\u00fdsledkom s\u00fa odsadenia \u2014 medzerami a zbyto\u010dn\u00e9 riadky vystrihnut\u00e9, zmes tabov a medzier pre odsadenie, ale povolen\u00fd vzh\u013ead). <\/p>\n