Miért jött a git olyan későn?

UNIX haladó

A git ugye 2005 után jelent meg, és tulajdonképpen ez az első normális verziókövető. Mi az oka, hogy csak ekkor jelent meg? Gondolom nem hardware miatt... Az elméleti tudás hiányzott? Vagy csak nem volt rá igény?

Nem néztem bele a forráskódjába, de nem hinném hogy sokkal bonyolultabb, mint pl. egy C fordító, egy BASH implementáció vagy a Linux-kernel, pedig ezek jóval korábban léteztek.

( trey | 2020. 07. 06., h – 13:46 )

Szerkesztve: 2020. 07. 06., h – 13:55

Előtte Linus egy zárt forrású, Bitkeeper nevű holmit használt. Amikor politikai támadásokat kapott emiatt, nekiállt lecserélni. Mivel nem talált semmit, ami megfelelt volna, írt egyet. Annak ideján ezer HUP cikk volt ezzel kapcsolatban:

https://www.google.com/search?&q=Bitkeeper+site%3Ahup.hu

trey @ gépház

Sőt hiába van velünk évek óta, sokan még csak most kezdik el használni. Tovább megyek, a github segítségével (amikor elkezdtem oda pakolni majd public lett, mert jó; és lett fork és pull-request pár arduino-s projeknél) értettem meg a közösségi fejlesztés értelmét.

A kerék is ilyen feltalálás volt, csak hamarabb elterjedt.

De, a git-re mindvégig megvolt az igény, és valóban nem bonyolultabb, mint egy C fordító. De senki nem gondolt rá, hogy ilyet írjon. Azért 2005-ben jött ki, mert Torvaldsnak akkor lett ki töke a béna verziókövetős szutykokból, amit akkortájt használtak, és szenvedtek velük régóta. Belátta, hogy akkor lesz ez is normális, ha saját kezűleg megcsinálja ő, és nem vár a sok agilis módszertanos debilre. Elterjedt meg azért lett ennyire a git, mert azonnal belátta minden fejlesztő, hogy verhetetlen. Ennyi. Nem kell ebbe sokat belelátni, meg fejtegetni.

Szerintem initrendszert is írhatna egyszer, hogy ne ilyen Pöttyering-típusú kretének írják azokat is, hanem normálisan meg legyen csinálva, egyszer, de végleg. Lehet 2030-ig fog tartani, mire elege lesz ebből is, és megcsinálja normálisra végül ő.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Why did you create Git?

Torvalds: I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world (with the possible exception of databases ;^), and I hated all SCM’s with a passion. But then BitKeeper came along and really changed the way I viewed source control. BK got most things right and having a local copy of the repository and distributed merging was a big deal. The big thing about distributed source control is that it makes one of the main issues with SCM’s go away – the politics around “who can make changes.” BK showed that you can avoid that by just giving everybody their own source repository. But BK had its own problems, too; there were a few technical choices that caused problems (renames were painful), but the biggest downside was the fact that since it wasn’t open source, there was a lot of people who didn’t want to use it. So while we ended up having several core maintainers use BK – it was free to use for open source projects – it never got ubiquitous. So it helped kernel development, but there were still pain points.

That then came to a head when Tridge (Andrew Tridgell) started reverse-engineering the (fairly simply) BK protocol, which was against the usage rules for BK. I spent a few weeks (months? It felt that way) trying to mediate between Tridge and Larry McVoy, but in the end it clearly wasn’t working. So at some point I decided that I can’t continue using BK, but that I really didn’t want to go back to the bad old pre-BK days. Sadly, at the time, while there were some other SCM’s that kind of tried to get the whole distributed thing, none of them did it remotely well.  I had performance requirements that were not even remotely satisfied by what was available, and I also worried about integrity of the code and the whole workflow, so I ended up just deciding to write my own.

https://iotguru.cloud

De azt ígérted, hogy most vallástalanítva leszek, erre beidéztél egy olyan szösszenetet, ami engem erősít meg. Kiemelem neked a megfelelő részeket: I really never wanted to do source control management at all... there were still pain points. ...while there were some other SCM’s that kind of tried to get the whole distributed thing, none of them did it remotely well. ... I had performance requirements that were not even remotely satisfied by what was available, and I also worried about integrity of the code and the whole workflow, so I ended up just deciding to write my own.

Más szavakkal ugyan, de ezt írtam én is, nem akart ilyennel foglalkozni, de az nem volt elég jó, amit használtak, kinőtték, alternatíva meg nem nagyon volt, így kénytelen volt egyszer nekidurálni magát, és saját maga megírni. Azóta van megcsinálva normálisan. Lenne még pár terület, amivel foglalkozhatna, szerintem sanszos, hogy azokban szintén maradandót alkotva többet profitálna belőle az egész opensource világ, mint a Linux kernelből. Nem mintha a kernel nem lenne fontos, de az már viseli a keze nyomát, abban már nem tud nagyon annyira újat beletenni, csak koordinálja már.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

De azt ígérted, hogy most vallástalanítva leszek, erre beidéztél egy olyan szösszenetet, ami engem erősít meg.

Nem én ígértem. De ha úgy érzed, hogy téged erősít meg, akkor valami párhuzamos univerzumban élsz vagy komoly szövegértési problémáid vannak, gyakorlatilag nem lenne Git, ha open source lett volna a BitKeeper, amit gyakorlatilag lemásoltak és újraimplementáltak.

https://iotguru.cloud

Igen, abban igazatok van így utánaolvasva, hogy licencdíj baj volt inkább vele. De ez engem nem cáfol teljes mértékben, hogy azért próbáltak belenyúlkálni a kódjába, mert funkcionálisan sem felelt meg, ezért bukták a licencet később, amivel eredetileg nem volt gond. A lényeg, hogy korábban Linus nem érezte szükségét, hogy verziókövető rendszert írjon.

Ez egyébként mindenkivel így van, csak kicsiben, hogy van egy hiányzó funkció vagy idegesítő feature, az ember szenved vele egy ideig, aztán ki lesz a töke, és csak akkor lép ellene valamit ilyen apró workaround lépések helyett, és vagy megírja magának vagy keres másik alternatívát.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nézd, te nagyjából azt állítottad, hogy

a) ilyen koncepciót soha senki még a félisten linus előtt nem. " De senki nem gondolt rá, hogy ilyet írjon." -- Dehogynem a BK ilyen volt.

b) A BK szar volt. mert "Torvaldsnak akkor lett ki töke a béna verziókövetős szutykokból, amit akkortájt használtak, és szenvedtek velük régóta" -- ezzel szemben "BK got most things right".

A baj az, volt, hogy a szabadságharcosok egy része nem használta "but the biggest downside was the fact that since it wasn’t open source, there was a lot of people who didn’t want to use it." aztán jött egy még öntudatosabb szabadság harcos, aki úgy gondolta, hogy márpedig ő szarhat más licence feltételeire, amiből az nézett ki, hogy a BK előbb utóbb nem lesz ingyen opensource fejlesztéshez sem. Linus ezért úgy döntött, hogy lekopizza "I decided that I can’t continue using BK, but that I really didn’t want to go back to the bad old pre-BK days".

Szóval igazából abban van igazunk, hogy totálisan teljesen félremagyarázod ezt az egészet.

Az a baj a vallásosokkal, hogy nem igazán érdekli őket a valóság. Nem ígért neked senki semmit. Nem arra haraptál aki eredetileg "megbántott".

Én csak a hupot olvastam a témában, igazából elég csak ezt a topicot, követve a linkeket, de nem az a kép rajzolódik ki amit te fent leírtál. 

Mert nem csak szutykok voltak, Linusnak jó volt a bitkeeper. Zártsága miatt írta meg a git-et, amit ihletett a bitkeeper. De akkoriban készült a mercurial is, és nem volt egyértelmű hogy melyik a jobb, de Linus miatt természetesen nagyobb hype volt a git körül. Mikor széles körben elterjedt a git, Linus már rég nem fejlesztette. 

Amúgy én szeretem a gitet, bár csak koca felhasználója vagyok. De más verziókezelőt még annyira sem ismerem, mint a gitet, ezért nem állok bele verziókezelős észosztásba, főleg nem vallási hittétel kinyilatkoztatásba. 

A maga modjan, de szerintem azt irta le (igaz felueltesen), amit a Torvalds idezet is elmond.

Yepp, ott volt a BK. De zart volt. Ha jol ertettem a topiknyitot, akkor a kerdes az Open Source / Free SCM-ekre vonatkozott -> A BK evvel kiesik.

A mercurial meg... ahogy azt angol nyelvteruleten szoktak mondani: tul keves tul keson. Talan. Ami szamomra hasonlo meretu projekt, az illumos kernelt pl. sokaig mercurialban fejlesztettek. Aztan valahogy azt is inkabb a githubon fejlesztik ma mar.

A git-nek ott volt a masik nagy dobas, ami segitett az elterjedeseben: A github. A higanyosnak nem volt ilyenje vagy hasonloja.

Na ezt kérlek fejtsd ki bővebben. Rövid ideig kénytelen voltam használni Mercurialt, az alapján az jött le, hogy felhasználói szemmel elég jó közelítéssel ugyan azt tudja mint a git, csak más a parancsok neve meg néhol a logikája. Logikusabbnak mondjuk pont nem éreztem, pedig ilyen szempontból azért parancssorig git sem ideális. Ja meg hogy a githez képest tetvesen lassú már egy közepesen nagyobb projektnél is.

Amikor közöm volt hozzá még kevésbé volt abszolút egyeduralkodó a git (akkoriban migrálgattak még sokan SVN-ről), de már akkor is egyértelmű volt hogy a git felé halad a világ, leginkább önszopatásnak éreztem a mercurial erőltetését.

Mercurial esetében ritkán használjuk a parancssort, a TortoiseHg workbench annyira nagyon jó és intuitív.

A mi cégünknél Hg-ről váltottunk gitre, és mindenki visszasírja a mercurialt. A mi projectjeink esetén nem volt sebességprobléma (a git szerver kicsit lassabb).

Mercurial esetén a leghülyébb manager is megértette a brancheket, a workflow-ot. A merge-et szinte lehetetlen volt elbaszni. Perceket vett igénybe 5-6 fejlesztő munkájának a merge-e a release candidate branch-be, és mindenki fasza diffeket látott egy intuitív guiban.

A git nagyon pilotavizsgas. A branch koncepcioja jo, de idióta módon komplikált az Hg után.

Mindent 5x annyi idő megcsinálni, mint mercurialben.

3 év git, 4 év Hg és kb 10 év svn a tapasztalatom. Az svn egy fos mindkettőhöz képest.

Kb +1

Az utolsó nagy gites projekt, amin dolgoztam, ott a working copy volt 1-2 GB, a teljes repo meg úgy tíz-tizenöt, hát ember legyen a talpán, aki azzal valami értelmeset tud kezdeni. Az, hogy egy push <100 sor változtatással 5 perc még semmi, mert a cigi-kávé-pisi kombóval végülis elmegy az idő, de az ellenségeimnek sem kívánom, hogy egy 1000+ fájlt érintő merge conflictot gitben kelljen megoldania. :) Az meg, hogy volt vagy 500+ branch, már csak hab a tortán.

Amúgy itt visszautalnék a "miért kell access control repon belül" - hát ezért. A kognitív képességei minden embernek végesek, rengeteg szopás jön abból, ha több team dolgozik ugyanazon a szemétdombon. :)

Az, hogy egy push <100 sor változtatással 5 perc még semmi, mert a cigi-kávé-pisi kombóval végülis elmegy az idő,

Már miért ne lehetne közben tovább dolgozni?

de az ellenségeimnek sem kívánom, hogy egy 1000+ fájlt érintő merge conflictot gitben kelljen megoldania.

Miben könnyebb egy 1000 fájlt érintő merge conflictot megoldani?

van hozzá bármi gitlab/github szerű?

Nagyon régen rajta van a bakancslistámon, hogy megnézzem egyszer, mert a gitnek minden jó dolga ellenére szerintem alapvetően kilóg a bele, sokkal sokkal jobban, mint azt kéne.

 

szerk: ez kérdés akart lenni :)

Nem politikai tamadasok miatt cserelte le, hanem volt egy kis adok-kapok, hogy akkor most visszafejtettek-e a kodot, vagy sem, ugyhogy megszuntettek az ingyenes hasznalatot:

But ultimately McVoy, still annoyed, chose to recall the free version of his client software in late April. From now on, open source developer or not, if you want to use BitKeeper, you must pay.

 https://www.infoworld.com/article/2670360/linus-torvalds--bitkeeper-blunder.html

( asch v | 2020. 07. 06., h – 14:02 )

Biztos, hogy nem volt előtte más hasonlóan jó eszköz, ami véletlenül nem terjedt el? Azért jó sok féle verziókezelő volt a piacon már előtte is. Nem ez lenne az első eset.

( persicsb | 2020. 07. 06., h – 14:04 )

Voltak előtte is jól használható verziókezelők, csak éppen nem voltak elég jók a Linux kernel fejlesztési folyamatához. És a git 2005-ös állapotát ne hasonlítsuk a mai git tudásához. Romantikus gondolat azt hinni, hogy a git 2005-ben is olyan jól használható volt, mint most.

( kubi | 2020. 07. 06., h – 14:05 )

Igeny volt, es ki is elegitette egy csomo megoldas. Az IBM es a tobbi nagy SW ceg portfoliojaban ott volt a verziokoveto rendszer is. Sulyos penzekbe kerult, igy legalabb nem csak a fejlesztoknek fajt, hanem a managementnek is :)

( uid_4263 v | 2020. 07. 06., h – 14:07 )

"CollabNet founded the Subversion project in 2000 as an effort to write an open-source version-control system which operated much like CVS but which fixed the bugs and supplied some features missing in CVS"

https://en.wikipedia.org/wiki/Apache_Subversion#History

Nyilván az svn már modelljében tök különbözik a gittől de azért mai szemmel is "normálisnak" nevezném. A CVS-hez meg a többi őskövülethez képest biztosan. Tehát már 2000 körül elindult ez, nem csak 2005-ben. És emellett volt/van egy raklap fizetős dolog is.

Szerintem kisebb dolgokra a git is pont ugyanannyira jó. Semmi indokot nem látok az abandonware erőltetésre a nosztalgián kívül. Főleg nem új repok esetén tartom abszolút hülyeségnek bevetni egy eltemetett eszközt csak azért mert ma még jó. Aztán lehet, hogy eltelik egy év és már több dolog kell oda. Te meg aki meghoztad ezt a brilliáns döntést már máshol randalírozol, és lehet migrálnia a következő szerencsétlennek. :)

Arra próbálok kilyukadni hogy invalid mondás az "egyszerű ez, használjunk rá svn -t" mert egy modernebb eszközt is lehet egyszerű dolgokra használni. És nem tudok róla hogy ennek bármi költsége vagy hátránya lenne.

"A git pedig teljesen más workflowra van kitalálva"

Érthető. Mindkettőt ismerem.

Az SVN használata pedig folyamatosan visszaszorul, senki nem választja már új repok számára (szinte), hiszen értelmetlen választás. Az abandonware alatt erre céloztam.

Az SVN használata pedig folyamatosan visszaszorul, senki nem választja már új repok számára (szinte), hiszen értelmetlen választás. Az abandonware alatt erre céloztam.

Ez inkább divat. Aztán meg jönnek a szopások, a körbetákolások és a kompromisszumok. Van egy csomó olyan valid workflow, amire a git teljesen alkalmatlan.

https://iotguru.cloud

Például szeretnél külön CI/CD folyamattal kezelni microservice halmazt, amelyek egymástól alapvetően függetlenek vagy maximum lazán csatoltak.

Ilyenkor jön Git esetén a monorepo hell, amikor mindenhez külön repository van, ha forrást vinnél át egyik microservice-ből a másikba, akkor elveszik az előélete az adott forrásrészletnek és/vagy trükközni kell egy csomó eszközzel.

Vagy a másik opció a bigrepository hell, amikor minden egyben van, aztán csak kamillázol, hogy ki csinált micsodát, melyik branch módosult, egyáltalán milyen struktúrába szervezed a dolgaidat, mit jelent ilyenkor a branch, melyik microservice melyik verziója az adott branch, a tag mit takar, mert akár vertikálisan, akár horizontálisan teszed egymás mellé a dolgokat, mindenképpen szopás lesz. Ezt lehet tetézni azzal, hogy egy adott ágra nem tudsz jogot szűkíteni, bíznod kell abban, hogy nem basszák el az egész repót.

Ezen már többször is átrágtuk magunkat, a vége mindig az, hogy vállvonogatás van a Git-only világban.

https://iotguru.cloud

Ilyenkor jön Git esetén a monorepo hell, amikor mindenhez külön repository van, ha forrást vinnél át egyik microservice-ből a másikba, akkor elveszik az előélete az adott forrásrészletnek és/vagy trükközni kell egy csomó eszközzel.

Csak a gitet hell hozza hasznalni, vannak ra parancsok (filter-branch meg masok), egyedul a commit ID veszik el - valtozik meg.

A big/monorepo ugyanugy svn-nel is megvan, nem? Meg ez filozofiai kerdes, ha sok komponenst kell egyszerre valtoztatni es releaselni, nekem a monorepo a szimpatikusabb.

A jogosultságkezelésben ami git alatt nem megoldható, az a láthatóság tiltása. A git a technikai megvalósítása okán minden kliensre leklónozza a teljes repót - legalábbis azt a branchet, amit az adott usernek el kell érni. Folderekkel tehát nem megoldható, hogy lehessen olyan információ a repóban, amit egyes userek nem látnak. AFAIK nincs erre a problémára megoldás egyetlen repón belül.

SVN-ben ellenben simán be lehet ilyen konfigurálni, mivel ott a klineseken csak az a részfa látszik, amin az adott user dolgozik. Emiatt egybként sok esetben jelentősen tárhelytakarékosabb a felhasználók gépein az SVN, mint a git.

git pushnál meg lehet oldani a szűrést, hogy ki mibe írhat bele, az írási jog korlátozása teház nem volna gond technikailag, vannak is példák rá.

AFAIK nincs erre a problémára megoldás egyetlen repón belül.

Ilyenkor jön a minden szarra külön repó és vele együtt a szopás.

git pushnál meg lehet oldani a szűrést, hogy ki mibe írhat bele, az írási jog korlátozása teház nem volna gond technikailag, vannak is példák rá.

Csak hákolni kell, illetve ingyenes megoldás (eddigi tudomásom szerint) nincs arra, hogy valamilyen user directory adja a hozzáférési jogokat.

https://iotguru.cloud

SVN esetén milyen megoldás van arra hogy valamilyen user directory adja a hozzáférési jogokat? Pl Alice +rw jogot kap a /branches-re, de csa +r jogot a /trunk-ra. Bob meg mondjuk mindkettőre +rw.

Amikor még - v1.6 környékén - üzemeltettem szervert, akkor fájlban adtuk meg és nem is emlékszem más alternatívára. (Szerk: user grouppokat kezelt, azt hiszem azokat össze lehetett kötni LDAP csoportokkal. Erre gondoltál?)

SVN esetén milyen megoldás van arra hogy valamilyen user directory adja a hozzáférési jogokat? Pl Alice +rw jogot kap a /branches-re, de csa +r jogot a /trunk-ra. Bob meg mondjuk mindkettőre +rw. Amikor még - v1.6 környékén - üzemeltettem szervert, akkor fájlban adtuk meg és nem is emlékszem más alternatívára. (Szerk: user grouppokat kezelt, azt hiszem azokat össze lehetett kötni LDAP csoportokkal. Erre gondoltál?)

Nem, a konkrét hozzáférési listát nem az user directory adja (bár megoldható, de kell hozzá egy kis script, csináltam ilyet is korábban); igen, a "group" tud jönni LDAP felől, a hozzá tartozó hozzáférési listát pedig lehet definiálni vagy közvetlenül az svnaccess fájlban vagy pedig generálva azt valamilyen egyéb eszközzel, tehát nem kell felhasználókkal bajlódni egyedileg, ha csoportba vannak sorolva és a csoport megfeleltethető egy hozzáférési körnek.

https://iotguru.cloud

Így viszont nem látom mi az amit a git ne tudna ebből. Nem üzemeltetek git szervert, ezért lehet hogy hülyeséget írok, de:

  • A git tud SSH authentikációt, ezáltal minden olyan PAM backendet támogat, amit az SSH - pl LDAP.
  • POSIX usergroup-pokkal kezelhető fájlszinten a jogosultságok köre (vagy esetleg acl-lel). A git segít is annyiban, hogy git init --shared után eleve figyeli a csoport jogokat fájl létrehozáskor.
  • Ennél szofisztikáltabb hozzáférés ellenőrzésre ott van a szerver oldali pre-recieve szkript, ami akár egy svn_authz szerű ini fájlt parse-olhat, de akár ez is lekérdezhet LDAP-ból és akkor a jogosultság kezelés is teljesen egy helyen történik.

Persze tévedés joga fenntartva. :)

Már leírtam két hozzászólással feljebb:

A git a technikai megvalósítása okán minden kliensre leklónozza a teljes repót - legalábbis azt a branchet, amit az adott usernek el kell érni. Folderekkel tehát nem megoldható, hogy lehessen olyan információ a repóban, amit egyes userek nem látnak. AFAIK nincs erre a problémára megoldás egyetlen repón belül.

Tehát az olvashatóságot nem tudod kontrollálni a repón (valójában egy kommiton) belül. Mindenki vagy az egészet látja, vagy semmit.

Össze-viszza vagdalkodást látok a kommentek közt... a legértelmesebb komment az volt, hogy a flowhoz kell választani eszközt. Persze nem árt, ha a flow is átgondolt.

Btw, a git submodule-t még meg sem említette senki. Bár lehet sok esetben a külön verziózott library megközelítés még jobb, mint a modul hash-ének karbantartása a fő repóban.

Komolyabb projektekben meg eleve scriptek vannak a folyamatokhoz is, pont ezért, mert a mezei fejlesztők faék egyszerűek a verziókezelésben.

Annyit meg kell hagyni, hogy technikailag igaza van: SVN-nel tudsz lathatosagot korlatozni.

Gyakorlatban pedig neked van igazad: normalis cegnel, ha egyszer fejleszto vagy, akkor korlatozgatni, hogy ki mit lat, nem szokott sok jot elorevetiteni.

2016 elotti fejemmel azt mondtam volna, hogy ahh, ez max 1000 fo alatti kis garazscegeknel, eros startup/ open kulturaval van csak igy.

Most meg irunk 2020-at.

Vannak helyek bőven, ahol létezik a jogosultságkezelés intézménye, például bárki nem léphet be bármelyik szerverre, mégis mi a különbség, amikor nem engednek be bizonyos szerverekre, amikhez semmi közöd és aközött, hogy nincs jogod látni egy olyan forrásokat, amikhez semmi közöd?

https://iotguru.cloud

A verziókezelőben fájlokhoz férsz hozzá, a szerverek meg nem számítógépek.

Információhoz férsz hozzá mind a két esetben.

Mintha autót hasonlítanál hajóhoz vagy repülőhöz. Mindhez kell jogsi, s ennyi a hasonlóság.

Oszt? Mindegyikhez kell jogosultságkezelés adott esetben, hogy read jogod se legyen bizonyos dolgokhoz, ami Git esetén eléggé kihívás és pont ez a probléma a Mercurial esetén is.

https://iotguru.cloud

Termékfejlesztésben nem egyszer követelmény az, hogy ne lássa mindenki az új feature-t. Simán lehet olyan igény, hogy X team reszelje a meglevő kódot, miközben Y team nyomja az R&D-t, amit titokban kellene tartani. Persze lehet workaroundolni, de a közös repo kényelmesebbnek tűnik.

Itt azért érzek egy elég nagy ellentmondást:

Az utolsó nagy gites projekt, amin dolgoztam, ott a working copy volt 1-2 GB, a teljes repo meg úgy tíz-tizenöt, hát ember legyen a talpán, aki azzal valami értelmeset tud kezdeni. Az, hogy egy push <100 sor változtatással 5 perc még semmi, mert a cigi-kávé-pisi kombóval végülis elmegy az idő, de az ellenségeimnek sem kívánom, hogy egy 1000+ fájlt érintő merge conflictot gitben kelljen megoldania. :) Az meg, hogy volt vagy 500+ branch, már csak hab a tortán.

vs

Persze lehet workaroundolni, de a közös repo kényelmesebbnek tűnik.

A moduláris fejlesztés nem workaround, hanem a legtöbb szempontból jobb megoldás.

Itt szépen össze van hasonlítva a Monolith és Microservice architektúrákkal: What is a Modular Monolith?

Ebben a környezetben a teljes iOS, Android, Web, desktop, legacy desktop, backend, legacy-backend, adatbázisok, SAP, számlázó rendszer, raktárkezelő rendszer, CRM, CM és infrastruktúra komponensek teljes architektúrát hova tudod tenni? Ebben a komplex rétegrendben a microservice-től a monolitikus alkalmazásig minden van, amin többnyire architekturális és kis mértékben történelmi okokból nem tudsz változtatni.

Nagyon jók ezek a buzzword blogbejegyzések, de egy 10-15-20 éves konglomerátum fejlesztéséhez teljesen értelmetlen beszúrni, a világ meg tele van 10-15-20 éves konglomerátumokkal, amiknek a közelébe se szoktak szagolni azok, akik mindig csak nagy hangú elkezdőemberek és az első pár probléma megjelenésével rögtön mennek más céghez problémákat okozni.

https://iotguru.cloud

Pedig nincs. :) Az első idézet arról szól, hogy a Git nálam elégtelenre vizsgázott nagyméretű projekteknél, a második meg arról, hogy van olyan use case, amikor több team több feature-ön dolgozik (mindegy, milyen VCS-t használnak ehhez).

>forrást vinnél át egyik microservice-ből a másikba

Remélem itt funkciók mozgatására gondolsz, nem forráskód másolásra, mert olyat nem csinálunk.

Azért szokott vállvonogatás lenni erre a problémára a válasz, mert eleve az ilyen mozgatások nem túl gyakoriak (főleg érettebb szakaszában egy rendszernek, amikor a historyra több a szükség), de komolyabban visszanézni history-t meg igencsak ritkán kell.

A git ezzel szemben a mindennapi életet nagyban megkönnyíti SVN-nel szemben, illetve csomó olyan nagyon jól működő workflow-t tudsz benne könnyen megvalósítani, ami SVN-ben (szinte) lehetetlen lenne.

Remélem itt funkciók mozgatására gondolsz, nem forráskód másolásra, mert olyat nem csinálunk.

Miért ne mozgatnék egész forráskódot? Amikor kiemelek egy forráskód blokkot például egy új microservice-be és/vagy library-be, akkor szeretném tudni az előéletét, hogy honnan jött és miért úgy alakult a szerkezete.

Azért szokott vállvonogatás lenni erre a problémára a válasz, mert eleve az ilyen mozgatások nem túl gyakoriak (főleg érettebb szakaszában egy rendszernek, amikor a historyra több a szükség), de komolyabban visszanézni history-t meg igencsak ritkán kell.

Hogyne lenne szükség. Főleg, amikor komplex hibát kell nyomozni és ha megvan a hiba, akkor tudni akarod, hogy miért úgy lett megírva, ahogy, van-e még annak a struktúrának létjogosultsága, kijavítható-e vagy újra lehetne írni nulláról. Mindennapos dolog, amikor 10-15-20 éves rendszerekről van szó.

A git ezzel szemben a mindennapi életet nagyban megkönnyíti SVN-nel szemben, illetve csomó olyan nagyon jól működő workflow-t tudsz benne könnyen megvalósítani, ami SVN-ben (szinte) lehetetlen lenne.

Nem mindig, sok esetben a Git bonyolítja a helyzetet és nem tudsz olyan workflow-t megoldani vele, ami Subversion esetén alapból adott. A Git nem egy ultimate eszköz, ami mindenre is jó: van egy jól meghatározott feladatkör, amire mindennél jobb, van egy nagyobb halmaz, amire kompromisszumokkal elviselhető és van egy még nagyobb halmaz, amire egzaktul szopás használni.

Ha szerinted mindenre is jó, akkor három okból és ezek tetszőleges kombinációja miatt van így:
a, olyan feladatkörre használtad eddig, amire jobb
b, nem ismered eléggé az alternatív megoldásokat
c, vallási okokból jól tűröd a szopásokat

https://iotguru.cloud

( _Franko_ v | 2020. 07. 06., h – 14:39 )

tulajdonképpen ez az első normális verziókövető

Az első ingyenes elosztott és offline működést támogató verziókövető, ami világszinten elosztott kernel fejlesztésre nagyon jó.

Amúgy szerintem egy olyan kés, aminek csak pengéje van, ha nem elég óvatosan fogod, akkor eléggé nagy károkat lehet okozni nálad és másoknál is.

Például máig használok Subversion-t olyan projektekre, ahol nincs elosztott működésre igény, ám jogosultságkezelés kell és nem akarok minden egyes kis microservice-re külön repository-t.

https://iotguru.cloud

( Nyosigomboc v | 2020. 07. 06., h – 14:50 )

Volt CVS meg SVN is, ahogy mar irtak. Ami nagy kulonbseg, hogy a Git decentralizalt, es a fontosabb muveletekre sokkal gyorsabb/hatekonyabb nagy projectek eseten. Kisebb cegeknel pl. az SVN hatranyai nem jonnek ki, mert egyszeruen mennyisegileg nincs annyi kod, hogy szenvedjenek miatta. Nagy projectek es cegek eseten meg max. tesznek ala meg vasat, vagy elviselik.

A Linux kernel egyreszt tul nagy ahhoz, hogy ne jojjon ki a tobbi hulyesege, masreszt a decentralizaltsag eleg nagy elony (amire korabban nem jottek ra). Nekik muszaj volt valami hasznalhato.

A strange game. The only winning move is not to play. How about a nice game of chess?

Van pár dolog azért ami svn-ben szenvedős és ósdi. Például a branch-ek svn-ben borzasztóak (mappák a fájlrendszeren). Tehát nem feltétlenül kiscég-nagycég tengely dönti ezt el. Nem véletlen hogy abszolút abandonware kategóriába esik és néhányan nosztalgiából használják ott ahol még elégségesnek bizonyol amit tud.

(a gitet is lehet egyszerű keretek között használni, nem hiszem hogy lehet objektíven érvelni azzal az esettel hogy "hát egyszerűbb dolgokra jó az svn". Ugyanakkor lehet hogy van olyan képessége az svn-nek amit véletlenül pont úgy tud, ahogy a git nem vagy nem egyszerűen, ez kivétel :)

Elképzelhető. Rákerestem arra a G-ben hogy "svn branches" és az első találat szövege így indul:

"Creating a Branch

Creating a branch is very simple—you make a copy of your project tree in the repository using the svn copy command. Since your project's source code is rooted in the /calc/trunk directory, it's that directory that you'll copy."

A branchek már nem mappák akkor? Van erről valami friss leírásod?

Az svn copy a szerveren hoz létre egy új branch-et, de ott sem történik valós fájlmásolás, csak a metaadatok jönnek létre, hogy mi volt a kiinduló revision. A talált leírás azért használja a directory szót, mert fájlrendszerszerűen érhetők el az egyes útvonalak (branche-ek, tag-ek, vagy akármik, mert a nevezéktan nincs megkötve.).

Olvasnivaló: http://svnbook.red-bean.com/

Inkább technikai és szakmai érveket hozzál fel, az óvoda máshol van. :) Én próbáltam nyitott lenni (és ezt írtam is feljebb) de úgy tűnik hogy elég hamar eljutottunk a szardobálásig. Sajnos.

De ha mondasz valamit az svn -ről amit nem vagy nem jól tudtam én el fogom olvasni.

Például a branch-ek svn-ben borzasztóak (mappák a fájlrendszeren).

Ez amúgy miért borzasztó? A metaadatai attól még ott vannak és pont ez miatt lehet jól jogosultság-kezelést használni.

Nem véletlen hogy abszolút abandonware kategóriába esik és néhányan nosztalgiából használják ott ahol még elégségesnek bizonyol amit tud.

Nem abandonware. Te gondolod így.

https://iotguru.cloud

Ha van egy alkalmazásod amit 5 ember fejleszt 8 branchen akkor összesen 30 40 darab IntelliJ példányt kell ráindítani ha SVN-ezel. Ez a gittel összevetve ahol mindig csak egy working copy van és szabadon váltogathatod hogy éppen melyiket mutassa fel, ósdi.

De ha hiányzik a jófajta svn életérzés akkor clone-ozol annyi repót ahány branchet akarsz és mindegyiken checkoutolod az adott branchet. :)

"pont ez miatt lehet jól jogosultság-kezelést használni."

git -ben is lehet branchenként jogosultságot kezelni, maximum a megfelelő git provider kell hozzá, de fejből nem mondom meg neked hogy pontosan melyikben hogy van. gitlab -ben például biztos hogy van.

Sajnos nem tudtam meg olyan új információt ami az svn mellett bármilyen scenarioban is érv lenne.

Ha van egy alkalmazásod amit 5 ember fejleszt 8 branchen akkor összesen 30 40 darab IntelliJ példányt kell ráindítani ha SVN-ezel.

Az IntelliJ nem tud valami egyszerűbb workflow-t? Az IntelliJ+SVN kombó eddig kimaradt, de meg lennék lepve, ha erre a setupra (ti. egynél több branch létezik) nem gondoltak volna, amikor az SVN plugin készült.

Ide is beszállok. :)

"a gittel összevetve ahol mindig csak egy working copy van és szabadon váltogathatod hogy éppen melyiket mutassa fel"

Az svn esetében is egyszerre egy working copy van és svn switch paranccsal váltasz a különböző branch-ek között. A legtöbb IDE támogatja (Eclipse és NetBeans biztosan, azokat használtam korábban erre).

git -ben is lehet branchenként jogosultságot kezelni, maximum a megfelelő git provider kell hozzá, de fejből nem mondom meg neked hogy pontosan melyikben hogy van. gitlab -ben például biztos hogy van.

Ez nem csak a commit jogokra vonatkozik? Meg lehet csinálni, hogy egy user lássa mondjuk a mastert, és a neki érdekes brancheket, de más brancheket ne?

Ilyenkor a git clone mit csinál? Mi a git branch -a outputja?

Ha van egy alkalmazásod amit 5 ember fejleszt 8 branchen akkor összesen 30 40 darab IntelliJ példányt kell ráindítani ha SVN-ezel.

Bocsánat, de lófaszt.

Ez a gittel összevetve ahol mindig csak egy working copy van és szabadon váltogathatod hogy éppen melyiket mutassa fel, ósdi.

Pont ugyanígy megy Subversion esetén is. Sőt, lehet staging-szerűen váltogatni egy branch-en belül is, hogy éppen min dolgozol. Átváltasz másik Jira issue-ra és kapsz egy új changelist-et, amit külön tudsz commit-olni.

De ha hiányzik a jófajta svn életérzés akkor clone-ozol annyi repót ahány branchet akarsz és mindegyiken checkoutolod az adott branchet. :)

Bocsánat, de lófaszt.

git -ben is lehet branchenként jogosultságot kezelni, maximum a megfelelő git provider kell hozzá, de fejből nem mondom meg neked hogy pontosan melyikben hogy van. gitlab -ben például biztos hogy van.

Define branch. Van 100 microservice-ed, hogy korlátozod le, hogy a "team A" férjen hozzá 50 microservice-hez, a "team B" pedig 75 microservice-hez, a "team C" meg csak 10 microservice-hez. És persze mindegyik tudjon tetszőlegesen branch-et és tag-et létrehozni, de ne lássa, amit nem kell látnia.

Sajnos nem tudtam meg olyan új információt ami az svn mellett bármilyen scenarioban is érv lenne.

Cserébe tudtál mondani csípőből és magabiztosan néhány oltári nagy faszságot a Subversion-ről.

Én amúgy 40-60 százalék arányban használok Subversion - Git verziókezelőt és projekt use-case függvénye, hogy melyiket választom, nem csak halvány emlékeim vannak arról, hogy melyik mit tud, hanem aktívan dolgozom mind a kettővel.

https://iotguru.cloud

>Van 100 microservice-ed, hogy korlátozod le, hogy a "team A" férjen hozzá 50 microservice-hez, a "team B" pedig 75 microservice-hez, a "team C" meg csak 10 microservice-hez. És persze mindegyik tudjon tetszőlegesen branch-et és tag-et létrehozni, de ne lássa, amit nem kell látnia.

Hát én biztosan nem monorepóval. Külön repó minden projektnek repó szintű jogosultságokkal, amit a teamek kezeljenek ahogy nekik jól esik. A közös kódrészletek külön repó(k)ba rakva amit a microservicek behúznak függőségként. Ehhez/ezekhez közvetlenül csak egy kiemelt maroknyi senior fér hozzá, a teamek meg forkolják szépen és aztán küldik vissza a változtatásokat upstreambe, amit el kell fogadnia a kiemelt fejlesztőknek.

Nekem ez tűnik a legtisztább megoldásnak. Ebből is lehet káosz, de az SVN mappa(?) jogosultságos bohóckodásból meg szinte csak azt tudom kinézni. Főleg hogy már egyre inkább csak githez fogsz találni fejlesztőt, SVN-nel alapból szerencsétlenkedni fognak, nem hogy ha egy nagy monorepó van jogosultságokkal, mindennel megkavarva. Én használtam pár évig SVN-t és van amire elég tud lenni, de egy ilyen workflowban nagyon rosszul érezném magam és valószínűleg folyamatosan a shortcutokat keresném a rendszerben. Infósokat nem érdemes szívatni, korlátozni, valahogy mindig visszanyal a fagyi a végén.

Hát én biztosan nem monorepóval. Külön repó minden projektnek repó szintű jogosultságokkal, amit a teamek kezeljenek ahogy nekik jól esik. A közös kódrészletek külön repó(k)ba rakva amit a microservicek behúznak függőségként.

Na, haladunk... ez egy kurva nagy workaround, ami nem oldja meg a problémát, csak kicsit kevésbé lesz kényelmetlen.

Ehhez/ezekhez közvetlenül csak egy kiemelt maroknyi senior fér hozzá, a teamek meg forkolják szépen és aztán küldik vissza a változtatásokat upstreambe, amit el kell fogadnia a kiemelt fejlesztőknek.

Aham, és ha nincs kiemelt fejlesztő? Gombhoz a kabátot?

Én használtam pár évig SVN-t és van amire elég tud lenni, de egy ilyen workflowban nagyon rosszul érezném magam és valószínűleg folyamatosan a shortcutokat keresném a rendszerben.

Az a pár év mikor volt? És miért gondolod, hogy más workflow rossz, akkor is, ha azzal lehet jobban haladni az adott körülmények között, a Git workflow meg tömény szopások sorozata?

https://iotguru.cloud

"Na, haladunk... ez egy kurva nagy workaround, ami nem oldja meg a problémát, csak kicsit kevésbé lesz kényelmetlen."

A francokat workaround. Az a normális, hogy a közös kód saját repoban van (egyszer), és tartozik hozzá egy folyamat ami eljuttatja a friss verziókat az artifact kezelőbe (nexus artifactory whatever) és a függőben levő alkalmazások az adott toollal (mondjuk maven) szépen letöltik. Ha akarjuk, akkor az artifact nem csak binárisban hanem forráskódban is fent van, így nem kell visszafejtett kódot nézegetni.

Nincs duplikáció, kényelmes, működik, jó a fejlesztőnek, jó a toolingnak. Ez szerinted workaround?

A francokat workaround. Az a normális, hogy a közös kód saját repoban van (egyszer)

Oké, nézzünk egy életszerű példát, némi absztakcióval.

Team A1, A2, A3: három projekt, három mobilalkalmazással, a cég három fő profilját lefedve, hívja a cég publikus backend szolgáltatásait. Vannak közös részek kiemelve közös library-ba.

Team B1, B2: négy projekt, négy mobilalkalmazással, a cég három fő profilját lefedve, plusz egy privát szolgáltatást, hívja a cég publikus és privát backend szolgáltatásait. Vannak közös részek kiemelve közös library-ba.

Team C1, C2, C3, C4: nyolc Windows vastagkliens, a cég három fő profilját lefedve, plusz a belső folyamatok támogatására megírva, hívja a cég publikus és privát backend szolgáltatásait, plusz közvetlen adatbázist. Vannak közös részek kiemelve közös library-ba.

Team D1, D2, D3: a cég három fő profiljának a backend szolgáltatásit fejlesztik, kettő ebből microservice architektúra (együtt ~100 microservice, ~30 közös, ~25 publikus API-t biztosít), egy pedig monolitikus. Vannak közös részek kiemelve közös library-ba. Vannak közös microservice-ek. Vannak közös adatbázissémák.

Team E: asset library kezelése.

Team F: "titkos" új projekt.

Team A1, A2 és B1 közös asset készletet használ, Team A3 és B2 szintén. Team C1, C2, C3, C4 saját asset repository-t használ. Team E írhassa mindenkinek az asset library repóját. Team F láthasson mindent.

--

Hogyan építenéd fel a source repository-t, hogy mindenki csak ahhoz a forráshoz férhessen hozzá, amit _láthat_ és azt a forrást módosíthassa, amihez joga van (közös library, asset, microservice forrás). Ha több repository van, tudjon a megoldás összevont pull request támogatást. Várom a javaslatod.

https://iotguru.cloud

Bevallom, nem igazán értem, hogy itt mi lehet a gond a fent említett megoldással, hogy minden "közös dolog" saját repoban van.

Pl. A1 projekt esetén R1, R2, R3, R4, R5 repo van használva.
R1, R2: írás/olvasás jog.
R3, R4: csak olvasás jog. (Pull Request a közreműködéshez)
R5: privát dolgok, csak binárisan férnek hozzá.

Bevallom, nem igazán értem, hogy itt mi lehet a gond a fent említett megoldással, hogy minden "közös dolog" saját repoban van.

Nem A1 projekt van, hanem A1 team, amelyik dolgozik egy projekten, amin B1 és C1, C2, D1 és az E team is. És van egy másik projekt, amin dolgozik A1 team, B2, C2 és C3 és D1, D2, D3 és az E team is.

A több mind 100 microservice hova kerül nálad? Milyen módon tudod elkerülni egy repóban azt a zajt, amit heti 300-400 branch okoz? A belőlük generált dokumentáció hova kerül?

Pull Request a közreműködéshez

És _ki_ a PR felelős? Melyik team melyik embere?

https://iotguru.cloud

Nálam egy-egy projekt X db modulból áll, amelyek mindegyike külön repoban van.
A fenti három típusba esik mindegyik egy adott team szempontjából. (Read/Write, Read, Binary)

A több mind 100 microservice hova kerül nálad?

Mindegyik külön repoba.

Milyen módon tudod elkerülni egy repóban azt a zajt, amit heti 300-400 branch okoz?

Nincs zaj, mivel nincs 300-400 branch egy repoban.

A belőlük generált dokumentáció hova kerül?

Az adott modulhoz (repo, microservice).

És _ki_ a PR felelős? Melyik team melyik embere?

Mindegyik repo-hoz külön dedikált személyek azok közül, akik R/W joggal rendelkeznek hozzá.

Mindegyik külön repoba.

Na, ez az igazi adminisztrációs hell. Mennyi volt az a repository-szám, amit kezelned kellett egy cégnél? Mennyi volt évben a legrégebbi commit?

Nincs zaj, mivel nincs 300-400 branch egy repoban.

Hogy mozgatsz ki például egy közös library-ba kódrészletet, osztályt, fájlokat, hogy megmaradjon a history, hogy honnan jött és ott miért úgy alakult?

Mindegyik repo-hoz külön dedikált személyek azok közül, akik R/W joggal rendelkeznek hozzá.

Oké, de ha projekten dolgozik 4-5 különböző csoport, akkor közülük ki? Mekkora volt aktív fejlesztőszámban a legnagyobb cég, ahol ezt a sémát követted?

https://iotguru.cloud

Mennyi volt az a repository-szám, amit kezelned kellett egy cégnél?

Jelenleg 700+ repositoryt látok olvasható jelleggel és közülük olyan 50-100, amihez van írási jogom, ezekhez van MR jogom is.

Hogy mozgatsz ki például egy közös library-ba kódrészletet, osztályt, fájlokat, hogy megmaradjon a history, hogy honnan jött és ott miért úgy alakult?

Sosem volt még ilyenre szükségem, de ha lenne, akkor így.

Oké, de ha projekten dolgozik 4-5 különböző csoport, akkor közülük ki?

Egy csoport van csak, aki a projekt fő részéért felel.

Mekkora volt aktív fejlesztőszámban a legnagyobb cég, ahol ezt a sémát követted?

300 fő.

Jelenleg 700+ repositoryt látok olvasható jelleggel és közülük olyan 50-100, amihez van írási jogom, ezekhez van MR jogom is.

És ez mennyi projekt része?

Egy csoport van csak, aki a projekt fő részéért felel.

Ja, így könnyű. És ez a csoport 300 fős? Vagy a 300 főből 5-10 foglalkozik ezzel a 700+ repository-val?

Sosem volt még ilyenre szükségem, de ha lenne, akkor így.

Sose volt refactor? Vagy sose volt arra igényed, hogy ha egy forrásrészlet megy common library-ba vagy két microservice közös forrásrészlete megy egy közös library-ba, akkor meglegyen a history? Amit linkeltél, az kivitelezhetetlen 700+ repository esetén és úgy, hogy kimazsolázd 5-10 év történelméből azt, hogy mi volt az adott osztály előzménye.

Amúgy elmennék egyszer üzemlátogatni, mert ez túlságosan szép ahhoz, hogy igaz legyen, még nem voltam olyan helyen, ahol ne lett volna tonnányi panasz, workaround, kiskapu vagy adminisztrációs hell, amikor ennyi külön repository élt.

https://iotguru.cloud

És ez mennyi projekt része?

Fogalmam sincs, nem is érdekel.

Ja, így könnyű.

Persze, épp erről beszélek ;-)

És ez a csoport 300 fős? Vagy a 300 főből 5-10 foglalkozik ezzel a 700+ repository-val?

Egyik se. Egy-egy modulon max. 5-10 ember dolgozik (bedolgozhat más is MR-rel), a projektek fő részein, meg max. 15-20 (bedolgozhat más is MR-rel).

Sose volt refactor? ...

Hogyne lenne. Arra nincs igény, hogy 5-10 év története egy adott helyen legyen. Ha valami átmegy egyik modulból a másikba, akkor ott lesz a link, hogy melyik modulból jött, ott megtekinthető a korábbi története. Nagyon ritkán van ilyenre igény, általában csak a közelmúlt az érdekes.

Fogalmam sincs, nem is érdekel.

Nézd, így bármit meg lehet magyarázni, hogy miért jó.

Hogyne lenne. Arra nincs igény, hogy 5-10 év története egy adott helyen legyen. Ha valami átmegy egyik modulból a másikba, akkor ott lesz a link, hogy melyik modulból jött, ott megtekinthető a korábbi története. Nagyon ritkán van ilyenre igény, általában csak a közelmúlt az érdekes.

Aham, szóval körbe van tákolva és szőnyeg alá vannak söpörve a maradék problémák, mint annyi helyen. Tényleg érdekel az üzemlátogatás, hogy a csapatnak amúgy mi a véleménye és ténylegesen hogy működnek a dolgok, mert még mindig úgy látom, hogy túl szép ez ahhoz, hogy igaz legyen. Ha viszont igaz, akkor sokat tudnék belőle tanulni.

https://iotguru.cloud

Két fő nagy problémánk van nagy projekt esetén:

  1. Keresés. Pl. mi hol van implementálva, mert az átkozott DIc elrejt sok dolgot. DIc-t kéne még elfelejteni. A másik meg az Exception, amit el kellene felejteni.
  2. Dependency probléma. Egy-egy modul más verziójú lib-et akarna használni.

Van egy jó videó a témában, de sajnos nálunk még nem működik ennyire jól a dolog.
Szóval ne hozzánk gyere, hanem inkább ezt a videót nézd meg ;-)

Van egy jó videó a témában, de sajnos nálunk még nem működik ennyire jól a dolog.

Aham, tehát leírtad, hogy mi a cél, de kurva messze vagytok a céltól, tele vagytok a szokásos problémákkal.

Szóval ne hozzánk gyere, hanem inkább ezt a videót nézd meg ;-)

Én alapvetően takarítani szoktam az üveggyöngy emberek után, akik minden héten találnak valami kurvaérdekes dolgot egy új projekt-library-philosophy kapcsán, ami miatt félbehagyják az előző heti kurvaérdekes dolgot az akkori új projekt-library-philosophy kapcsán, aztán eltelik fél-másfél év, és megpattannak, maguk mögött hagyva a félbehagyott dolgokat és a füstölgő romokat, hogy egy újabb áldozat cég életét keserítsék meg. Na, ez a videó pont ilyenről szól, ahogy végiggörgettem a témákat.

https://iotguru.cloud

( ibenny v | 2020. 07. 06., h – 15:21 )

Egyaltalan nem jott keson, mai napig sem haszanltam soha (mondjuk nem is vagyok ugye fejleszto). :D

( ssikiss | 2020. 07. 06., h – 16:13 )

Hát... IMHO volt egy adag NIH szindróma is a git születésénél - mint az a komolyabb agyaknál általában hajlam.

Már akkor is egész jó elosztott verziókezelők (monotone, mercurial, darcs) léteztek, és egyik-másiknak nem kellett volna sokat fejlődni ahhoz, hogy megfeleljenek neki - legalább is "elméletileg".

Ha jól emlékszem, a monotone volt pl. az egyik jelölt - amit megnézett Linus annak idején. De hát k*rva gyors merge meg egyszerű tárolás kellett...

Azert ha a monotone eletkepes lett volna, akkor megmaradt volna ('14-ben tartott az 1.1-nel, azota nincs release). A mercurial nem tud tortenelmet hamisitani, de hasonlo a githez.

Emlekeim szerint olyan '12-14 korul a Python (CPython) is mercurialban volt, ma meg mar githubon van helyette. Erdekes valtas. Lehet, masok is a higany->git iranyban mozognak.

Alapvetően ennek nem az az oka, hogy mindenben és mindenre jobb a Git, mint bármi más, hanem az, hogy a Git köré a megfelelő időben épült egy GitHub, és hasonló dolog a többi köré meg nem épült és/vagy már későn kezdtek bele, a GitHub mellett pedig nem nagyon lehet már piacot szerezni, akkor sem, ha jóval többet adsz, mint a GitHub.

https://iotguru.cloud

Mi mint szoftverfejlesztő cég 2008 körül svn-t kezdtünk használni, kb 2010-12 körül git és mercurial közül a mercurial vonalat választottuk, főleg a jobb windows-os toolset és nagyon jó webgui (Rhodecode, most kallithea) miatt miatt, végül 2016 környékén a gitnél és gitlab-nál kötöttünk ki.

Akkoriban a mercurial tudásban fej-fej mellett haladt a git-el, mostanra lehet ez már nem áll. Több kisebb projekt esetén most is jó megoldás az svn de ettől függetlenül nálunk egy projekt kivételével mindenki átállt git-re.

Több kisebb projekt esetén most is jó megoldás az svn de ettől függetlenül nálunk egy projekt kivételével mindenki átállt git-re.

Szerintem nem a projekt mérete a vízválasztó, hanem a projekt workflow. Lehet a Git kis projektre jobb, a Subversion meg nagyobb projektre jobb, ha épp az a workflow. A probléma abból van, amikor mindenre egy eszközt erőltetünk, mert az a divat vagy az azt ismerjük. Ha nincs igény földrajzilag elosztott működésre; viszont korlátozni szeretnénk a projektek láthatóságát, írhatóságát; nem akarunk polyrepo modellt, akkor ingyenes megoldások közül nagyjából a Subversion jön szóba.

https://iotguru.cloud

( KGer | 2020. 07. 06., h – 17:53 )

Szerkesztve: 2020. 07. 06., h – 17:57

ott volt a clearcase is, nagyon nem volt álom de nagy céges többmillió soros projekteknél 10000+ féle custom branch-nél 1000+ fejlesztőnél bizonyítottan jól ment, használtam

( nagyjoco | 2020. 07. 06., h – 21:16 )

Az nagyvállalati IT egyre inkább a Hegylakó sorozatra kezd hasoníltani, csak egy maradhat!

Desktop Linux- Ubuntu

Szkript nyelv: Python

Adatcsere: JSON

Automatizáció: Ansible

Verziókövetés:Git

A git egyszerűen azért népszerű, mint a Python, a nagyok azt használják, függetlenül attól, hogy valóban a legjobb eszköz-e a feladatra.

( uid_6201 v | 2020. 07. 06., h – 21:53 )

Szerkesztve: 2020. 07. 06., h – 22:10

Kinek későn? Linus megalkotta a BitKeeperrel való nézeteltérés után ... 2 hetes szabadsága alatt. Aztán továbbreszelték.
GitHUB-ot mint GIT-re épülő webes szolgáltatást 2008-ban alapították. Azóta velünk van.
A hazai szabadszoftver konferencián is ekkortájt már voltak előadások róla, miért célszerű használni a saját (céges) projektjeinknél: https://vimeo.com/47964675
GIT verziókövetőt is ekkortájt már élesben használtuk céges projektekben.

Mi lett az új? Hogy akik például Subversionba tették a forráskódjaikat, azok is az elmúlt években átálltak erre?
Megjegyzem, ha nem lett volna Linus, akkor nem lenne GIT. Továbbá akkor sem, ha nem veszik össze akkor a BitKeeperrel, mert alapjában véve a Linux kernel forráskódját jól tudta azzal is menedzselni.

( deje | 2020. 07. 07., k – 12:41 )

Ez nem bírom ki, muszáj leírnom: a git biztosan jó, mert egymilliárd légy nem tévedhet!

Sok előnye van a többihez képest. Egyébként ki emlékszik, amikor a Sourceforge-on adatvesztés történt? Örültek volna akkor ők is egy elosztott repónak, ahonnan vissza tudták volna rakni az összes hiányzó projektet az összes előzményével együtt.
Sajnos nem kis munka egy frankó verziókezelő megalkotása, így ha valaki nagyon elégedetlen a meglevőkkel, akkor áll csak neki újnak. :)

Én is csináltam már fasza rendszert 2 hét alatt, aztán megtetszett cégnek, utána hárman reszeltük több mint fél éven át, mire nagyjából jó is lett. Szóval nem tévesztendő össze valaminek a PoC verziója azzal, ami már production ready.

https://iotguru.cloud

Picit kötekedem: gondolod, hogy abba a 2 hétbe belefért a funkciók megálmodása is, vagy 2 hét arra volt elég, hogy elvonulva a már a fejében létező tervei alapján lekódoljon egy "már tudok vele kódot verziókezelni" valamit, amit utána évekig fejlesztettek, hogy hasonlítson a mai GIT-re?

The development of Git began on 3 April 2005. Torvalds announced the project on 6 April; it became self-hosting as of 7 April. The first merge of multiple branches took place on 18 April. Torvalds achieved his performance goals; on 29 April, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 patches per second. On 16 June, Git managed the kernel 2.6.12 release.

https://en.wikipedia.org/wiki/Git#History

Hogy a nevezetes április harmadika előtt mennyire volt meg a koncepció, nem tudom.

"Hogy a nevezetes április harmadika előtt mennyire volt meg a koncepció, nem tudom."

Gondolom ha a Bitkeeper mukodott, es nem volt vele semmi gond, akkor a BK hiszti elso jelet tennem a legkorabbi olyan datumra, aminel elkezdett gondolkodni a koncepcion. Amikor egy eszkoz mukodik, es teszi amit varsz tole, akkor nincs ok arra, hogy a cseren agyalj.

A strange game. The only winning move is not to play. How about a nice game of chess?

( arpi_esp v | 2020. 07. 07., k – 20:03 )

volt elotte bitkeeper, svn is, es ezek csak az ingyenesek, mar 2001-ben is leteztek nagy komoly es iszonyat draga szoftverek erre...

en meg a mai napig a sajat kis projektjeimet cvs-ben tartom mert azt szoktam meg az mplayer idejen, es arra amire hasznalom boven eleg.

( evone | 2020. 07. 09., cs – 18:24 )

te miért 9 éve regisztráltál a hupra? miért nem 20 éve? akkor is volt hup végülis. nem hiszem hogy akkor sokkal bonyolultabb lett volna regisztrálni. mik ezek a kérdések lol?

Pedig a tortenelemben ezek az igazan jo es erdekes kerdesek, nem az, hogy mikor volt az 1066-os csata (delelott negyed tizenegykor).

Az, hogy hogy vezetnek bizonyos esemenyek bizonyos masik esemenyekhez (mondjuk a WWI utani igazsagtalan bekeszerzodesek a 2. felvonashoz), es ebbol hogy lesz a vegen - a katonai alkalmazas utan - sugarhajtasu utasszallito, atomeromu, vagy szamitogep. Vagy neha miert nem lesz (gorogok mar hasznaltak elemet, ismertek a gozgepet, stb.).

Persze a veletlennek is sokszor van szerepe. Amikor megprobalod megmerni a germaniumlemez bizonyos parametereit, es meres kozben folyton valami hulyeseg jon ki. Vagy amikor a rossz pillanatban zavar meg valami..

Átkelt az olajos padlón, megtöltötte a teavízforraló kannát és beékelte a kovácstűzhely sarkába. Fölvett egy villáskulcsot, hogy elvégezzen némi végső beszabályozást a Kombinált Betakarítógépen, és észrevette a falnak támasztott kaszát.

...

Büszkén pillantott a Kombinált Betakarítógépre. Persze, kell hozzá egy ló, hogy húzza. Az kicsit ront a dolgon. A lovak a Tegnaphoz tartoznak; a Holnap a Kombinált Betakarítógépé és utódaié, ami a világot tisztább és jobb hellyé fogja tenni. Csupán annak kérdése, hogy a lovat kivonja az egyenletből. Már megpróbálkozott a lendkerékkel, de az nem volt elég erős. Talán, ha megpróbálna megfeszíteni egy...
Mögötte a vízforraló kanna túlforrt és kioltotta a tüzet.
Fekete átverekedte magát a gőzön. Ez a nyavalyás probléma, minden egyes alkalommal. Valahányszor valaki megpróbálkozik némi ésszerű gondolkozással, mindig történik valami értelmetlen, ami eltereli a figyelmét.

A strange game. The only winning move is not to play. How about a nice game of chess?