Virtuális Git fájlrendszert jelentett be a Microsoft

 ( trey | 2017. február 5., vasárnap - 12:02 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

--
trey @ gépház

Ezen kicsit meglepődtem. Főleg, hogy Linus fejlesztette ki a linux kernel forrásának kezeléséhez :)

Ezek szerint jó másra is, és Redmondban is felismerték. Another Linux brick in the wall - ah, window...

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

Akarsz beszélni róla? :)

Üdv,
Marci

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

Akartam mondani... legalább vették volna a fáradtságot, és adtak volna neki valami szép májkroszoftos nevet.

Microsoft Virtual File System Services for Professional Developers 2017, Git Edition, powered by Bing?

Üdv,
Marci

Valami ilyesmit... de az eredeti bejelentésben ezt nem látom, viszont a GVFS-t csak 11-szer :)

Kimaradt, hogy Enterprise. :)

Microsoft Enterprise-Scale Semi-Distributed Cloud Virtual Stored Source Code Management System Professional Edition 2017, Anniversary Insider Preview

Egy rugóra járt az agyunk :)
Te nyertél!

Üdv,
Marci

:D
--
"Sose a gép a hülye."

Nem lennék meglepődve, ha a Microsoft átnevezné.

Üdv,
Marci

+1
--
"Sose a gép a hülye."

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).

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?

A cikk szerint minden.

Üdv,
Marci

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.

"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.

Mi ezzel a probléma?

Üdv,
Marci

Nincs history.

Milyen hátrányokkal jár ez a fejlesztés további szakaszaira?

Üdv,
Marci

Komolyan?

Igen, komolyan. Nem értek hozzá, oszt' nem szégyellek kérdezni-tanulni.

Üdv,
Marci

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)

Értem, köszönöm!

Üdv,
Marci

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:

  1. 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.
  2. 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.
  3. 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.

Köszönöm!

Üdv,
Marci

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.

--

Egyetértek, de...

- const defaultCommentsPerPage = 300
+ const defaultCommentsPerPage = 3000

Érthető a kód?
Tudod, hogy miért kellett megváltoztatni a kódot?

Mert a kozosseg megszavazta :)

Azt hiszem, egy momentumot elfelejtettél figyelembevenni a hír olvasásakor.
Konkrétan arra gondolok, hogy ezt a kódot közzétették a githubon.

Innentől kezdve, kicsit nehezen tudom elképzelni, hogy senki nem akar majd PR-eket küldeni rá.

Hozzáértést tükröz. Valszeg az alapprobléma is valahol ez lehet amire a csodás megoldást "kifejlesztették".

--
Gábriel Ákos
http://ixenit.com

es a visual sourcesafe?! az nekik smafu?!

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

oszinten remelem, hogy nem :)

--
NetBSD - Simplicity is prerequisite for reliability

Pedig van hasonlóság :-)

Fogunk még config spec-et írni.

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.

Ha jól emlékszem, azt volt az egyik fő bajuk, hogy az index file ~400MB, és egy git status-hoz azt mindig végig kellett olvasni. Most valahogy úgy csinálják, hogy a legtöbb fileról (amik nem változnak úgysem) a git nem is tud....

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)

Szerintem kapcsolódhat, valószínűleg ez az ok.
Amúgy a Win32 név a Windows alrendszer neve az NT-ben, mindegy, hogy 64 vagy 32 bites, csak hogy teljes legyen a kavar...
A WOW64 pedig a 64 bites Windowsok 32-bites emulációja :)

Üdv,
Marci

Értem. Köszi. Hát, mindig tanul az ember újat.

Esetleg egy próbát tehetsz saját felelősségre:
https://mspoweruser.com/ntfs-260-character-windows-10/

szerk: ó bocs, úgy látom friss normál rendszeren még nem elérhető. Lehet még mindig csak insider.

Némi háttérinfó itt: Git Is Taking Over Microsoft

Üdv,
Marci

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…

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

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.

Idézet:
„A kliens kódot pedig elérhetővé tette MIT licenc alatt a GitHub-on.”

Az értő olvasás hasznos dolog.

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

Szerintem pont ezt a megallapitast tette.

:)

Akkor meg nem értem a hozzászólását, hiszen amit írt, az szerepel a cikk végén is.

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

Vezesd le kérlek, hogy ez neked hogy jött ki!

Nekem ez a következtetés, kicsit... erősen Update Norbis magyarázatnak tűnik!

http://www.hwsw.hu/hirek/56795/microsoft-fejlesztoi-eszkozok-git-one-windows-gvfs.html

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