Befejeződött a GCC SVN->Git konverzió

Hosszú és fájdalmas menet volt, de csak sikerült.

Nézzük is át a "teljes" menetet.

  • 2014. november 10.: Eric S. Raymond (ESR) egy év után sikeresen konvertálta a GNU Emacs forráskódját GNU Bazaar-ról Git-re. ESR ezzel együtt felhívta a nyílt forrású projekteket, hogy váltsanak CVS-ről is Git-re.
  • 2015. február 10.: ESR válaszul Richard Stallman-nek, aki kritizálta az LLVM debugger használatát az Emacs projektben, kijelentette, hogy az LLVM-é a jövő és sokkal jobb compiler, mint a GCC és a világnak fel sem tűnne, hogy ha a GCC egyik napról a másikra eltűnne.
  • 2015. augusztus 23.: Miután ESR tudomást szerzett arról, hogy a GCC fejlesztők arról tanakodnak, hogy a korábban használt SVN-t le akarják cserélni Git-re, felajánlotta hogy segít véghez vinni a konverziót a saját Reposurgeon programjával. Közben hozzátette, hogy a korábbi CVS->SVN konverzió összekavarhatott néhány dolgot, amit javítani kell.
  • 2015. augusztus 27.: ESR saját Patreon oldalán kezdett gyűjteni a GCC konverzió segítésére.

Egy kis ugrás az időben:

  • 2018. július 8.: ESR bejelentette, hogy megoldotta az egyetlen fennmaradó technikai problémát, viszont ezzel együtt azt is bejelentette, hogy sajnos a saját 64GB RAM-al rendelkező gépen nem elegendő a konverzió végrehajtásához és sajnos 128GB DDR4-es RAM túl drága, így megoldást kell találnia a RAM használat visszaszorítására.
  • 2018. július 20.: ESR bejelentette, hogy sajnos újabb hibába futott a Reposurgeon fejlesztése és sajnos még egy PC upgrade sem segítene a helyzeten, mert nem lehetne párhuzamosítani a folyamatot, ezért bejelentette, hogy a Reposurgeon-t Python-ról Go-ra portolja, aminek számításai szerint 40x-es sebesség növekedést kell eredményeznie.
  • 2018. december 18.: ESR állítása szerint a Go port 90%-ban kész van és a GCC repón 3x-4x-es sebességet sikerült elérni, aminek következtében a számítások szerint 3 óra alatt véghez vihető a GCC konverzió, de további tuningolások szükségesek még.
  • Kis érdekességként 2019. januárjában az LLVM projekt is elkezdte a megbeszéléseket, hogy Git-re és GitHub-ra állnak át SVN-ről, melyhez saját eszközt fejlesztettek. A konverzió lezárását október 21.-re tervezve.
  • 2019. május 15.: A Linaro egyik fejlesztője, Maxim Kuvyrkov beküldött egy adag patch-et, ami egy 300 soros Bash szkripttel és az SVN és Git alapértelmezett eszközeivel elvégzi a konverziót.
  • 2019. május 19.: ESR válaszul Maxim patch-ére, kijelentette, hogy ő nem bízik a git-svn programban és szerinte hajlamos hibákat elkövetni a konverzióban.
    Ugyanezen levelében válaszul, hogy szeptemberre készen áll-e a Reposurgeon a konverzióra, azt válaszolta, hogy 65% az esélye, hogy igen.
    A System76-tól kapott egy AMD Threadripper-el szerelt gépet, hogy ezzel gyorsítsák a munkálatokat. Így ezzel a géppel már 15x-ös sebességnövekedést mért a Python verzióhoz képest.
    Állítása szerint a Go port már 90%-ban készen van, illetve felvetette, hogy ha egy lelkes C programozó szeretné, akkor a Go verziót átírhatná C-re.
  • 2019. október: Az LLVM csapata meglépte a Git konverziót és az infrastruktúrájukat átdolgozását megkezdték.
  • 2019. december: A GCC csapata elhatározta, hogy december közepéig eldöntik, hogy ESR vagy Maxim megoldása mellett rakják-e le a voksukat, hogy az ünnepek alatt meglépjék a konverziót. Közben Maxim továbbfejlesztette a szkriptjét és már csak néhány hibát kellett orvosolnia. Közben ESR a Freenode-on demonstrálta a saját konverziós megoldását.
  • 2019. december 16.: A GCC csapata nem tudott teljesen dűlőre jutni, hogy akkor melyik konverziós megoldást is pártolják. A többség ESR megoldását pártolta, míg a többiek inkább a két konverziós megoldás eredményeit szerették volna összevetni, hogy melyik eredményez jobb végterméket. Közben ESR továbbra is kiállt amellett, hogy Maxim megoldása, hogy a git-svn -t alkalmazzák, nem túl okos döntés.
  • 2019. december 24.: ESR bejelentette, hogy szerinte a Reposurgeon már teljes mértékben készen áll a GCC konverzióra, már csak egy-két kisebb hibát kell orvosolni, de az nem gátolja a konverzió lefutását, így még egy-két nap halasztást kért, hogy javítsák a dolgokat.
  • 2019. december 29.: Maxim nyíltan megkérdőjelezte, hogy ESR megoldása készen áll-e a konverzióra, ugyanis több, igen komoly hibát is felfedezett a Reposurgeon-féle konverzióban és nem érti mihez ide, ennyi idő, mikor az ő megoldása már a nyár alatt készen állt a konverzióra és azóta nem volt nagyobb volumenű módosítás a kódjában, mint a Reposurgeon esetén. Maxim ajánlotta is, hogy egy hozzáértő fejlesztő hasonlítsa össze a Reposurgeon-féle kimenetet egy már létező Git-re konvertált GCC verzióval mielőtt bárki kijelenti, hogy ESR új megoldása készen áll a feladatra és jobbnak számít-e.
    Mindeközben a GCC csapatának még mindig nem sikerült döntenie a konverziós megoldások között.
  • 2020. január 8.: Joseph Myers bejelentette, hogy miután ESR megoldása kapott még néhány további finomítást már készen áll arra, hogy elvégezzék vele a konverziót.
  • 2020. január 11.: Megkezdődött a konverzió, ami reggel 8 órára le is futott.

Azóta a GCC már csak a saját infrastruktúrájukat igazítja a Git-hez.

Hozzászólások

OMG, a sztori így pontokba szedve olyan mint egy paródia bohózata. Amúgy belemenve a részletekbe biztos tényleg nehéz probléma ez, mert ESR nem hülye. Ha ennyi idejébe tellett a jó megoldás, akkor valami nehéz volt benne. Lehet, hogy öregszik is. Gratulálok mindenkinek aki dolgozott rajta, és reméljük nem lesz túl sok regresszió!

Ennyire rossz a Python teljesítménye a Golanghoz képest?

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

igen ;-)

python  nem rosz amikor a problema tenyleg I/O -ra var, vagy az esetek tobsegeben native library -bol szarmazo kodot hajt vegre,

vagy egyeb dark megic altal generalat kodot (GPU) ...

python kifejezetten szivas, ha egy shell loopol python cumokat hivsz.

A sima python code nagysagrendileg perl,ruby,php,javascript sebessegu.

Tobb szallusag limitalt, mindegyikben.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Azert nem egeszen.

Peldaul a python alapadatszerkezetei optimalishoz kozelibbek, mint a tobbi scriptnyelve.

De a kulso konyvtarakban tenyleg vannak borzalmasan bugos es optimalistol nevetsegesen tavol allo megoldasok. A "batteries included" egy illuzio.

Multithread: az tenyleg limitalt.

De ugye nem tévedek nagyot, ha úgy gondolom, hogy ettől függetlenül a Python még mindig scriptnyelv, azaz a kód interpretált futtatása versus a kód fordítása + futtatása áll egymással szemben?

A lenyeg:

Ami O(1) std::unordered_map-ban C++-ban, az legalabb python dict()-ben is O(1) lesz, PHP-ban meg kurvara nem, sehogy sem, orulj, ha az O(log n) osszejon az erre leginkabb hasonlito adatszerkezettel (array())

Erre ertettem, hogy "csak linearisan lassabb" (konstansszor annyi utasitas assembly-ben a pythonos valtozat, nem konstansszor valtozoszor annyi)

Azt teljesen biztosan tudom, hogy az AWK associative array néven emlegeti amióta egyáltalán létezik - azaz 1977-től legalább; a hashset mikori találmány? Nekem a hash legelőször a Perl-ből ismerős, ami deklaráltan az AWK után egy jó 10 évvel keletkezett. Ettől nyilván lehet hogy más nyelvekben / környezetben már korábban is előfordult bármelyik.

Nekem az volt a tapasztalatom, hogy speciel a tömb -> asszociatív tömb mint oktatási irány teljesen jól kezelhető volt, kb. senkinek nem okozott problémát megérteni, hogy a hash-t (vagy assoc array-t) úgy kell felfogni, mint egy olyan tömb, ahol az elemek eléréséhez használt index nem csak nem-negatív egész szám, hanem bármi más is lehet (jellemzően valami szöveglánc), e miatt pedig nyilvánvalóan az elemek "sorrend szerinti bejárása" nem feltétlenül egy átlagember számára is logikus sorrendben fog történni, és értelemszerűen a halmazokon értelmezett "eleme-e" egy létező tulajdonság. És kész.

Ez mind remek, csak a legalapvetőbb probléma az, hogy PHP-ban csak és kizárólag ez az izé van, ahelyett, hogy lenne

- egy rendes interface, hogy felsorolható típus (gyk.: oda lehet adni a foreachnak)

- lenne egy rendes tömbtípus

- lenne egy dictionary/hashset típus

Meg akkor már stack meg queue, de ilyen finomságokról már álmodni sem merek.

Sokkal sokkal lassabb. A Golang, akárcsak a Java, erősen típusos nyelv, azaz egy változóról tudható hogy mit takar. Ezzel szemben a Python értelmezőnek minden függvényhívás előtt futás időben meg kell vizsgálnia a típust amire meghívták, sőt még az argumentumok típusát is ki kell deríteni, így választódik ki a ténylegesen meghívandó függvény. Hogy ez mennyire összetett, hány függvényhívás rejlik pl egy sima "+" (összeadás) mögött, azt bemutatják itt:

How Python was Shaped by leaky Internals, Armin Ronacher, Flask framework

Az előadó többek között a lassúság okának nevezi meg, hogy olyan belső dolgok, amelyek a leírt bonyolult működést tudnák gyorsítani, kiszivárogtak (elérhetők a Python programból), ami csak tovább bonyolítja a dolgot.

A Python értelmező alatt általában CPython értelmezőt értik, amiről a video is szól. Más Python értelmezők jobb teljesítményt nyújthanak, de azok nyelvi értelmezést tekintve nem feltétlen 100% kompatibilisek a szabvánnyal, másrészt a Python lib-ek nagyrésze direkt a CPython-hoz készült és csak azzal működik.

Abból látszik h nem értek hozzá, h azt gondoltam volna, az aktuális svn "mastert" átviszik és mindenki onnan folytatja. (Sose használtam svn-t.)

Itt (meg máshol is) az volt a fő ok, amiért nem csak egy aktuális állapotot emeltek át és onnan folytatják, mert a teljes code history-t is át kell emelni, hogy később ha valamivel probléma van, akkor kiderüljön, hogy ki és mikor csinálta a módosításokat. Illetve az épp aktuális branch-ek is kellenek, hogy mindenki zavartalanul folytathassa a megkezdett munkálatokat.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Van... Említve is van, a git-svn. A Git saját tool-ja, hogy SVN repót behúzzon Git alá. Ez ellen emelt hangot ESR, hogy szerinte nem jó.

Maxim pont ezekre az eszközökre  alapozta a megoldását és nem egy teljesen új sajátot csinált, mint ESR.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

A `git-svn` igazából nem migrációs tool, bár arra is lehet használni.  A fő célja, hogy kétirányú kapcsolat legyen egy központi Subversion repo és a user Git repo-ja között, másszóval hogy Git-et használva is lehessen Subversionben tárolt projekten dolgozni.

Ami tényleg hivatalos "* -> Git" migrációs eszköznek tekinthető, az a fast-import stream formátum az azt feldolgozó `git fast-import` paranccsal.  Persze ehhez kell valami eszköz, ami ilyen stream-et köp ki magából: erre egyrészt ott a beépített `git fast-export` parancs, ha esetleg valaki Git-ről szeretne valami másra migrálni (vagy egy Git repo-n mindenféle átalakításokat eszközölni), és mindenki kedvenc internetes keresője szerint számos verziókezelőhöz (hg, bzr, svn, cvs, rcs, ...) elérhetőek hasonló fast-export eszközök.  Hogy ezek mennyire megbízhatóak, azt nem tudom, se azt, hogy a GCC migráció során próbálták-e ezt a lehetőséget (a fenti (egyébként remek, köszi) történeti áttekintés nem említi).

Checkout biztos megy, talán bármi a github-ról.

Létrehoztam egy teszt-repót a github-on, azt svn-nel checkout-oltam (nem git-svn-nel), egy teszt-commit (svn commit...) minden hiba nélkül lefutott és a githubon is megjelent. Komolyabban nem teszteltem.

Legalábbis én erre gondoltam, azaz nem feltétlen kell svn-t git-re konvertálni, hogy a github-on tudd használni - talán ez nem volt egyértelmű (utólag visszanézve a hozzászólásom).

(Szerk.: feljegyzést írtam korábban, hogyan lehet egy svn repot githubra tükrözni, bár ehhez git is kell)

Vajon milyen szinu lett a biciklitarolo? :)

remek forgatokonyv.

mikor mutatjak be a filmet ?

HUP te Zsiga !

Az ilyenek végén szokás megkérdezni, hogy 'emlékszik még valaki, miért is kezdtünk bele?'