K\u00e4es on Mergiraf 0.4 projekti uus versioon, mis arendab Git'i draiverit, v\u00f5imaldades kolmeosalist sulandumist. Mergiraf toetab erinevate konfliktide lahendamist sulandumisel ja seda saab kasutada erinevate programmeerimiskeelte ja failivormingute jaoks. Mergiraf'i saab kasutada iseseisva t\u00f6\u00f6tlusena konfliktide lahendamiseks tavalise Giti t\u00f6\u00f6 k\u00e4igus v\u00f5i asendada Git'i sulandumise t\u00f6\u00f6tlejaga, et laiendada selliste k\u00e4skude nagu merge, revert, rebase ja cherry-pick v\u00f5imalusi. Kood on litsentseeritud GPLv3 alusel. Uues versioonis on lisatud tugi Python, TOML, Scala ja Typescript keelte jaoks, samuti on t\u00e4iustatud j\u00f5udlust. <\/p>\n
Allpool on toodud \u00fcksikasjalik \u00fclevaade probleemidest, mida mergiraf aitab lahendada: <\/p>\n
Tarkvara on silmapaistev n\u00e4ide \u00e4\u00e4rmiselt keerulisest s\u00fcsteemist. Keerulistel s\u00fcsteemidel on \u00fcks \u00fchine omadus \u2014 nad on KEERULISED \u2014 ja te ei saa oodata, et vajalik keeruline k\u00e4itumine ilmuks iseenesest, juhuslikult. Selle asemel areneb need s\u00fcsteemid aja jooksul, samm-sammult, ning iga mutatsioon kontrollitakse hoolikalt igas etapis. Selle saavutamiseks on vajalik h\u00e4sti m\u00e4\u00e4ratletud struktuur ja sobivad t\u00f6\u00f6riistad. Iga keerulise s\u00fcsteemi evolutsioon on visualiseeritav suunatud puuna, kus juur t\u00e4histab t\u00fchja funktsioonide kogumit ja iga s\u00f5lm \u2014 v\u00e4lja arvatud juur \u2014 on mutatsiooni rakendamise tulemus oma vanemal. <\/p>\n
Toodete kontekstis nimetatakse iga s\u00f5lme \"versiooniks\", mis esindab kindlat funktsioonide ja antifunktsioonide komplekti. Iga sellise komplekti muutmist peetakse mutatsiooniks, mis moodustab serva meie suunatud ts\u00fckliteta graafikus. Need funktsioonid on oma olemuselt abstraktsed; need ei peegelda otseselt f\u00fc\u00fcsiliste s\u00fcsteemide toimimisviise, vaid pigem demonstreerivad, kuidas ratsionaalsed agendid tajuvad nende s\u00fcsteemide kasulikkust. Idee \u00fcmbertoomine reaalses maailmas eksisteerivatesse teostustesse n\u00f5uab k\u00e4iste \u00fcles t\u00f5stmist ja piisavalt madala tasandi detailidesse laskumist, keeles, milles on v\u00f5imalik v\u00e4ljendada ja selgitada, kuidas k\u00f5ik t\u00e4pselt t\u00f6\u00f6tab. Tarkvaraarenduses esindavad need madala tasandi detailid tavaliselt l\u00e4htekoodi. <\/p>\n
Koodi j\u00e4rkj\u00e4rguline viimine n\u00f5utud k\u00e4itumise seisu ja selle dokumenteerimine, kuidas nad sinna j\u00f5udsid, esitatakse programmeerijate poolt snapshot'ide ja changest'ide kaudu. Snapshot on toote kindel seisund koos k\u00f5ikide madalamate detailidega, samas kui changeset t\u00e4histab \u00fcleminekut snapshot'ide vahel. Tavaliselt genereeritakse snapshot'id nende vanemate juurde kuuluvate \u00fcksikute changeset'ide kaudu, seega need snapshot'id t\u00e4histatakse tavaliselt selle, mida need changeset'id teevad, mist\u00f5ttu neid termineid kasutatakse sageli vahetatult. <\/p>\n
M\u00f5nikord esinevad mitme \u00fclemineku tulemusel saadud snapshot\u2019id \u2014 kommitite sulandumise protsess. Nendega on keeruline t\u00f6\u00f6tada, seega neid tavaliselt v\u00e4ltitakse. Kaasaegsed avatud l\u00e4htekoodiga versioonihalduss\u00fcsteemid, nagu Git, pakuvad \u00fcsna lihtsaid v\u00f5imalusi arendusprotsesside haldamiseks. Need v\u00f5imaldavad arendajatel korraldada snapshot\u2019e suunatud ts\u00fckliteta graafides, m\u00e4rgistada need kommentaaridega ning vajadusel muuta nende j\u00e4rjestust. <\/p>\n
See funktsionaalsus v\u00f5imaldab arendajatel kirjutada semantiliselt olulist projekti ajalugu, mis on kriitilise t\u00e4htsusega t\u00f5rgete leidmiseks ja k\u00fcsimustele vastamiseks, nagu \"Miks see madala tasandi detail (nt, muutuja) lisati?\", \"Kui palju protsente on minu panus sellesse projekti?\", \"Keda r\u00fcnnati tagasil\u00f6\u00f6kide kaudu ja millal?\", \"Milline madala tasandi muudatus rikkus selle funktsiooni (kuigi see ei pidanud rikkuvat, me kontrollisime seda!?)\" <\/p>\n
Versioonihalduss\u00fcsteemid t\u00e4iendavad seda kontseptsiooniga harudest \u2014 madala tasandi m\u00f5iste, mis t\u00e4hendab lihtsalt pidevat madala tasandi projekti ajalugu, mis on arendajale semantiliselt oluline. Harusid kasutatakse tavaliselt konkreetsete funktsioonide teostamiseks, m\u00f5nikord luuakse mitu haru sama funktsiooni erinevate kandidaatide jaoks. Kasutades harundusprotsesse (mis on tegelikult peavool ja arendamise standard, mida kasutatakse igal pool ja kogu aeg), saab iga eraldi arendaja t\u00f5husalt hallata mitmeid projekti vastuolulisi harusid, millest iga\u00fchel on erinevad valmisoleku v\u00f5i kvaliteedi tasemed. See v\u00f5imaldab arendajatel kombineerida oma ja teiste t\u00f6\u00f6 tulemusi ilma, et iga kord oleks vaja k\u00f5ike k\u00e4sitsi \u00fcmber kodeerida. <\/p>\n
Tavaliselt luuakse p\u00f5hiharu, mis esindab \"ametlikku\" toodet, kust hargnevad k\u00fclgharud iga funktsiooni jaoks, mis regulaarset (ideaalis \u2014 p\u00e4rast igat commiti) s\u00fcnkroniseeritakse p\u00f5hiharuga, v\u00f5imaldades arendajatel t\u00f6\u00f6tada k\u00f5ige v\u00e4rskema toote versiooniga ja samal ajal rakendada funktsioone, mida nad parajasti arendavad, tuvastades v\u00f5imalikke probleeme teiste arendajate tegevustest nii varakult kui v\u00f5imalik. <\/p>\n
Proovides kombineerida erinevate snapshot'ide funktsioone (mis on lihtsalt \u00fchise esivanema leidmine ja muudatuste sekvenidine rakendamine \u00fche \u00fcle teise, on see operatsioon tuntud kui rebase, sulandumine on aga peaaegu nagu rebase, lihtsalt struktureerib commite graafi teisiti, mille t\u00f5ttu on neil ebamugav manustada, seega p\u00fc\u00fcavad nad sulandumist v\u00e4ltida rebase'ide kasuks) esinevad probleemid. Kaasaegsed versioonihalduss\u00fcsteemid (VCS) kasutavad sisemisi algoritme muudatuste \u00fchendamiseks, mis jagavad failid lihtsamateks ridadeks, k\u00e4sitlevad iga rida s\u00fcmbolina ning faile nende j\u00e4rjestustena, seej\u00e4rel rakendavad algoritme nende \u00fchendamiseks, mis on p\u00e4rit bioinformaatikast. <\/p>\n
Kahjuks ei seosta ridade kaupa esitatud l\u00e4htekood selle sisuga. Selle ainus v\u00e4\u00e4rtus on, et see on lihtne ja universaalne. Erinevused viivad konfliktideni, olles pidev peavalu arendajatele. Konfliktide lahendamine n\u00f5uab arendajalt p\u00f5hjalikku m\u00f5istmist m\u00f5lema koodi versiooni osas, sealhulgas mitte ainult ridade kaupa v\u00f5rdluse algoritmiga m\u00e4rgitud \u201emuudetud\u201d v\u00f5i \u201ekonflikti\u201d osi, vaid v\u00f5ib-olla ka kogu projekti. <\/p>\n
Arendaja peab m\u00f5istma muudatusi, kirjutama k\u00e4sitsi \u00fchendatud koodi ja lahendama k\u00f5ik erinevused. Probleemide arv suureneb, kui ridade kaupa t\u00f6\u00f6riist tuvastab muudatusi valesti, mis juhtub sageli suurte muudatuste korral, sealhulgas triviaalsete, nagu koodi \u00fcmbervormistamine. Kui hilisemaid muudatusi ei \u00f5nnestu k\u00e4sitsi \u00fchendatud koodile rakendada, muutub olukord t\u00e4ielikuks \u00f5uduseks. Hirmutavate juhtumite t\u00f5ttu t\u00f6\u00f6tab ridadesse p\u00f5hinev algoritm enamasti, eriti kui arendajad p\u00fc\u00fcavad aktiivselt mitte tekitada talle probleeme. \u00dcks viis selliste probleemide v\u00e4hendamiseks on n\u00f5uda, et l\u00e4htekoodid t\u00f6\u00f6deldaks kanoniseerimist\u00f6\u00f6riistadega, nagu black. <\/p>\n
\u00d5ige lahenduse leidmine hirmutavates olukordades (ja mitte ainult neile, ridade kaupa algoritm on heuristika, mis v\u00f5ib triviaalsetel viisidel viia mitte t\u00f6\u00f6tava koodi, n\u00e4iteks kui \u00fcks arendaja nimetab muutuja \u00fcmber ja teine samal ajal kirjutab uut koodi, mis seda muutuja kasutab, ei ole sulandumise\/edasi viimise konfliktiga, kuid tulemus on mittet\u00f6\u00f6tav) on \u00f5ige sisemise mudeli kasutamine. <\/p>\n
Hoolimata sellest, et selles valdkonnas on uurimist\u00f6\u00f6d tehtud juba umbes 30 aastat ja see on viinud mitmete patenteeritud kommertstootete loomise juurde, ei ole need uurimist\u00f6\u00f6d hiljuti praktilisteks rakendusteks avatud allikaga toodeteks muutunud. Enamik avatud l\u00e4htekoodiga lahendusi hakkas arenema 2010. aastate alguses ja keskendus peamiselt Java keelele. <\/p>\n
Selle perioodi silmapaistvaim avatud lahendus, GumTree, on loodud akadeemilise taustaga uurija poolt, kirjutatud Java keeles, omab oma abstraktset sisemist representatsiooni, mis eelnes treesitter'ile, ja omab nii treesitter'iga kui ka muude t\u00f6\u00f6riistadega p\u00f5hinevaid tagaplane, et parsimise l\u00e4htekood muutuks abstraktseteks representatsioonideks. See s\u00fcsteem suudab ainult genereerida (s\u00fcndmuste tekstil\u00f6gana, samuti on API, mida saab lihtsalt kutsuda mistahes programmeerimiskeelest, millel on Java sidemed) ja visualiseerida muudatusi. Siiski, muudatuste \u00fchendamiseks ega genereeritud diff-failide vaatamiseks, ei sobi see kohe (kuigi on t\u00f5en\u00e4oline, et diff-ide laadimise saab rakendada API kaudu). <\/p>\n
Noorem ja praktikas rakendatav difftastic lahendus, kirjutatud Rust'is, p\u00f5hineb treesitter'il ja keskendub eristatud diff-ide genereerimisele konsoolis. See s\u00fcsteem on samuti suunatud diff-ide visualiseerimisele ja ei sea oma eesm\u00e4rkideks muudatuste \u00fchendamist ega patchide rakendamist. <\/p>\n
Hiljuti on ilmunud ja aktiivselt arenemas projekt mergiraf. See Rustis kirjutatud t\u00f6\u00f6riist (v\u00f5tab 21 MiB!) p\u00f5hineb samuti treesitteril, mis on saanud sama standardiks kontekstivabade grammatika parsimisel arendust\u00f6\u00f6riistade jaoks kui LLVM madalama taseme k\u00e4su optimeerimise jaoks. Erinevalt konkurentidest pakub mergiraf funktsioone, mis ei genereeri diff-e, vaid automaatset sulandumisprobleemide lahendamist. Mergirafi all kasutab patchide genereerimisel GumTree algoritmi rakendust ning rakendamisel sporki algoritmi, mis on kohandatud treesitteri struktuuride jaoks. <\/p>\n
Pat\u0161ide serialiseerimist failidesse, mida saaks hiljem rakendada, kahjuks ei ole rakendatud (aga on t\u00e4iesti v\u00f5imalik, et see v\u00f5iks olla teostatav GumTree genereeritud s\u00fcndmuste logide parsimise kaudu). Teine perspektiivikas v\u00f5imalus erinevuste rakendamiseks v\u00f5iks olla erinevuste rakendamine mitte pat\u0161ide kaudu, vaid LSP-serverite refaktoreerimisfunktsionaalsuse kaudu, mis v\u00f5iks aidata avastada konflikte kogu projekti tasemel. Visualiseerimine toetab ainult konfliktilahendust. <\/p>\n
T\u00f6\u00f6 n\u00e4ide: \u00fchine eelk\u00e4ija \u201ebase.py\u201d (tabide kaupa sisesaldus, alguses liigne rida) foo = 1 def main(): print(foo + 2 + 3) \u201ea.py\u201d (tabide kaupa sisesaldus, 2 liigsest rida alguses, for debugging print on kaasatud icecream'i teek, lisatud klass \u201ebaz\u201d: from icecream import ic foo = 1 def main(): ic(foo + 2 + 3) class baz: def __init__(self): \u201e>>>baz>>>\u201d \u201eb.py\u201d (muutuja \u201efoo\u201d on \u00fcmber nimetatud \u201ebariks\u201d, t\u00f6\u00f6deldud black'i abiga p\u00e4rast muudatusi, mille tulemusena sisesaldused on ruudud ja liigsed read eemaldatud): bar = 1 def main(): print(bar + 2 + 3) Kutse .\/mergiraf merge .\/base.py .\/a.py .\/b.py -x a.py -y b.py -s base.py -o .\/res.py annab j\u00e4rgmise tulemuse from icecream import ic bar = 1 def main(): ic(bar + 2 + 3) class baz: def __init__(self): \u201e>>>baz>>>\u201d (for debugging print on kaasatud teek \u201eicecream\u201d, muutuja \u201efoo\u201d on \u00fcmber nimetatud \u201ebariks\u201d, t\u00f6\u00f6deldud black'i abiga p\u00e4rast muudatusi, mille tulemusena on sisesaldused ruudud ja liigsed read eemaldatud, tabide ja ruutude segu sisesaldustes, kuid lubatud vorm). <\/p>\n