Virtuális Git fájlrendszert jelentett be a Microsoft

Microsoft, Windows

A Microsoftnál számos olyan csoport van, amelyik rendkívül nagy Git tárolókkal dolgozik. Ott van például a Windows kódbázisa, amely több mint 270 GB-ot tesz ki és több mint 3,5 millió fájlból áll. A Git klienseket nem ilyen és ekkora tárolók kezelésére tervezték. A 3 órán keresztül tartó "git checkout" vagy az egyszerű "git status", ami 10 percet vesz igénybe, elég kontraproduktív. A Microsoft ezért kifejlesztette a Git Virtual File System-et, röviden GVFS-t. A kliens kódot pedig elérhetővé tette MIT licenc alatt a GitHub-on. Teszteléséhez Windows 10 Anniversary Update vagy frissebb operációs rendszer szükséges.

A bejelentés elolvasható itt.

( trey | 2017. 02. 05., v – 11:03 )

Már a Windowst is Git-tel fejlesztik?!?!?!

--
trey @ gépház

( BandiG v | 2017. 02. 05., v – 20:13 )

Meg mindig ilyen gagyi a bing? (Vagy ez meg a regi MS?)

( Oops | 2017. 02. 05., v – 11:44 )

Hmmm. Még egy GVFS... de jó, legalább lesz mit keverni.

( blackluck v | 2017. 02. 05., v – 11:45 )

Vajon meddig tartott volna megnezni van-e mar mas gvfs neven hogy ne keverjek ossze vele...
Biztos hosszu lett volna mondjuk egy gitvfs elnevezes vagy nehezen megjegyezheto a vfsfg (virtual file system for git).

( blackluck v | 2017. 02. 05., v – 11:51 )

Aki jobban ismeri arulja el pls, hogy az a 270GB - 3.5 millio file az egyetlen repo/branch lenne vagy az osszes egyutt tesz ki ennyit es valojaban nem kell a fejlesztoknek ekkora kodbazisokkal egyidejuleg mokolni?

Monorepo eljárást használnak, ami azt jelenti, hogy branchek nem nagyon vannak, csak trunk-ra (master, head, hívd aminek akarod) dolgoznak, és minden egy repóban van. Ugyanezt használja a Google és asszem a FB is. A fejlesztőknek nem kell a kódbázis nagy részét használni, de ennél a gites megoldásnál le kell tölteni - szerintem ez az érdekes a történetben, hogy kerestek egy verziókezelőt ami rohadtul nem az ő problémájukra van kitalálva, és aztán írtak hozzá egy komplex alrendszert, hogy valamilyen szinten használható legyen.

Nekem is ez jutott eszembe.

De egyébként azt mondta, hogy mindenhol git-re állnak át, hogy csak egy rendszert kelljen karbantartaniuk, és csak ezzel az egy repoval vannak ilyen extrém problémák.

De valszeg akkor is jobb megoldás lenne írni egy git-re hasonlító VC-t, hogy a UI tudás ne vesszen el, aminek a backendje képes ekkora repókat kezelni.

( sz | 2017. 02. 05., v – 12:27 )

"A kliens kódot pedig elérhetővé tette MIT licenc alatt a GitHub-on."

Az egészet egy óriási commitban, 328 changed files with 38,997 additions, csodás.

Ha azt kell megnézni, hogy egy kódrészlet miért azt csinálja amit csinál, akkor gyakran hasznos megkeresni "git blame"-el hogy melyik committal került bele, a változtatás maga és a commit szöveg gyakran segít megérteni. Én a gyarkorlatban így használom.

Egyébként szerintem érhető hogy amikor valami open source lesz, a history nem lesz az, nyilván a history tele van mindenféle nem publikus hivatkozásokkal / komponensekkel egy ekkora cégnél, hiszen valószínűleg nem tudták eleve, hogy open source lesz amit fejlesztenek. Nem is beszélve az olyan kódrészletekről, ami "belsőre jó lesz", de publikálni már gáz lenne. (és ez nem rosszindulat)

Nem is beszélve az olyan kódrészletekről, ami "belsőre jó lesz", de publikálni már gáz lenne. (és ez nem rosszindulat)
Dolgoztam olyan cégnél, amelynél voltak a szoftvereknek "customizációi" egyes ügyfelek számára. Egyszer előfordult, hogy egy ilyen customizációt kellett "productosítani". Újra lett írva az alapjaitól, kevésbé látványos, mert csak konzolosan konfigurálható (emellett többet tud), és hosszabb idő alatt készült el, de olyan a kódminőség, hogy felvállalható, karbantartható.

Nagyjából amit cus írt.

Én a forráskódban elhelyezett kommentek jobb alternatívájaként tekintek a verziókezelő historyra:

  • A kódhoz permanensen hozzárendelődik a commit message, így az soha nem lesz outdated. Ha a kód változik, ahhoz automatikusan új message keletkezik.
  • A commit message nem szennyezi a kódbázist, attól elkülönül. A kód a "hogyan", a commit message a "miért" kérdésre válaszol.
  • Lehetővé teszi, hogy behatároljuk, hogy egy megváltozott viselkedés (pl. bug :)) egész pontosan mikor, milyen változtatással, miért és ki által keletkezett (pl. git bisect), drasztikusan lecsökkentve az ennek felkutatására, megértésére fordítandó időt.

Hibajavításhoz tényleg jó néha a history, de nem mi fogunk hibákat javítani, hanem a Microsoft, nekik meglesz, nem kell közzétenni. Viszont ha a kód érthetetlen, és még komment sincs, az már régen rossz, ha már a historyt kell nézni hozzá, attól rossz kedvem szokott lenni, de szerencsére ez ritkán van.

--

( crown v | 2017. 02. 05., v – 15:52 )

es a visual sourcesafe?! az nekik smafu?!

( wachag | 2017. 02. 05., v – 18:06 )

Így folytatják, el fogunk jutni a ClearCasehez ;-).

( azbest | 2017. 02. 05., v – 18:17 )

Inkább azzal lehetett a problémájuk, hogy ntfs-en bajok vannak a könyvtármélységgel. A legtöbb git kliens a régi apit használja, ott pedig a közelmúltig kb 260 karakteres útvonal korlát volt a dos kompatibilitásra hivatkozva. A modernebb apit pedig még az ms megoldási sem használták. Végül úgy tudom registrivel már feloldható a limit, csak gondolom más problémájuk is lehetvele, pl hogy buildeléskor az ntfs fájlrendszerkezelés több időt visz el, mint a feladat. 2-3 éve én is rengeteget szívtam ezek miatt. Volt ahol cygwin volt bewrappelve a könyvtárváltáshoz, mert cmd-ből nem létezett az útvonal. Persze ezek a wrappelések sem segíti a teljesítményt.

Inkább azzal lehetett a problémájuk, hogy ntfs-en bajok vannak a könyvtármélységgel.

  1. Ez nem az NTFS limitacioja, hanem a Win32-es alkalmazasoke (Az NT kernelnek a Win32 csak egy alrendszere). Tehat eddig is, regota hasznalhattal hosszu 260+ konyvtarneveket NTFS alatt, csak nem garantalt, hogy az alkalmazasok kezelni tudjak, ezert inkabb le volt tiltva.
  2. A Windows 10-ben a 260 karakteres limitet kivezetik: https://mspoweruser.com/ntfs-260-character-windows-10/

--
"Never trust a computer you can't lift."

Nekem Win10 alatt a OneDrive for Business panaszkodik, hogy bizonyos fájlokat nem tud szinkronizálni, mert túl hosszú az elérési úttal a nevük.

Ez a probléma kapcsolódik a fentihez, vagy nem? (Az a sejtésem, hogy a Win32 alrendszert egyáltalán nem használja 64 bites windows esetén, ha a program 64 bites)

( nevergone v | 2017. 02. 06., h – 00:56 )

Csak Gabu meg ne tudja, hogy az MS is inkább Git-et használ és nem CVS-t! :)

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

( hnsz2002 v | 2017. 02. 06., h – 08:04 )

Troll: Miért nem a saját "nagyszerű" Team Foundation-üket használják?
--
"Sose a gép a hülye."

( szg0000 | 2017. 02. 06., h – 10:03 )

Tekintettel arra, hogy a git opensource, ennek a Git File System-nek is opensource-nak kell lennie.

____________________________________
Ha vita van, számoljanak órajelciklusokat. Egyesével.