Microsoft představil GVFS (Git Virtual File System)

Microsoft na svém blogu věnovaném vývojářům představil GVFS (Git Virtual File System). Cílem tohoto virtuálního souborového systému je urychlit práci s Git repozitáři. Soubory jsou stahovány až při jejich prvním otevírání. Microsoft uvádí, že například klonování obrovského repozitáře díky GVFS netrvá více než 12 hodin, ale pouze několik minut. Zdrojové kódy klienta jsou k dispozici na GitHubu pod licencí MIT.

3.2.2017 18:00 | Ladislav Hagara | Zajímavý software

Komentáře

[michal]

Ježišmarijá, microsoft.

[Sten]

Takže z distribuovaného verzovacího systému udělali centrální, který pro práci vyžaduje připojení k serveru? Oh yeah!

Mimochodem by mě zajímalo, jak často potřebují dělat plný git clone, že se jim vyplatí jej zrychlovat.

[stativ]

Jestli jsem to pochopil dobře, tak to kluci vykutálení vymysleli ještě líp. U centralizovaného systému máš soubory v checkoutované verzi. S GVFS nemáš ani to, místo reálných souborů tam budeš mít nějaký placeholder.

[Michal Kubeček]

Pro příležitostné nahlédnutí do gitu projektu, se kterým člověk rutinně nepracuje a ani to nemá v úmyslu, by to smysl mít mohlo. Jinak samozřejmě bude narážet na to, že se rychlý jednorázový clone na začátku mnohonásobně vrátí ve výrazně pomalejších běžných operacích při vlastní práci.

U toho use case, který tam popisují (kompletní codebase Windows, 3.5 milionu souborů, 270 GB) mi ale připadá, že zásadní chyba je už v tom, že to potřebují mít všechno v jednom repozitáři. Vždyť i kernel, firefox nebo libreoffice jsou počtem souborů i velikostí o dva řády níž (kromě počtu souborů u firefoxu, tam je to jen o jeden).

[d]

jediny repozitar je spravny pristup pro velky projekt, zvlaste kvuli zavislostem

stejne to dela napr google (android)

[Michal Kubeček]

Nemyslím, že je rozumné dívat se na celé Windows (tj. jádro, knihovny i aplikace) jako na jeden projekt v tomto smyslu.

[kralyk z abclinuxu]

git submodule

[J]

Vybavene :)

[Sten]

To tedy rozhodně nedělá. Android má několik desítek repozitářů.

[cronin]

Android to má skutočne vyriešené elegantne. Len keby niekto konečne z repo(1) urobil first-class aplikáciu, aby sa dala použiť na integráciu Git repozitárov vo všeobecnosti, a najmä, aby ju bolo možné používať bez Gerrit-u.

[xvasek]

LOL, takže oni to v začátku nepochopili (že si to mají rozdělit) a teď to kvůli tomu takto zprasují. Já jsem si dřív myslel, že to prasí úmyslně, ale že by to jenom neuměli mě nikdy nenapadlo.

[Kvakor]

Kdysi jsem na jednom blogu četl rozhovor onoho blogera s ex-zaměstnacem Microsoftu (co tam pracoval v čase zhruba do vydání Windows Vista) a tam se velikost a nerozdělenost codebase Windows zmiňovala - pokud se nemýlím, hlavní důvod byla provázanost interních mikrosoftích programů na různé části vnitřností systému, systémové i uživatelské knihovny a někdy i sebe navzájem, což samotný ex-zaměstnanec považoval za Zlou Věc.

[xkucf03]

Ano, v různých garážovkách mají ve zdrojácích zadrátované cesty jako C:\Dev\Produkt\… a běda kdyby sis chtěl dát zdrojáky jinam, nebude ti to fungovat. V MS asi dělají něco podobného.

[xkucf03]

Pro příležitostné nahlédnutí do gitu projektu, se kterým člověk rutinně nepracuje a ani to nemá v úmyslu, by to smysl mít mohlo.

Na občasné nahlédnutí jsou různé webové UI – které ti navíc můžou nabídnout i rychlé hledání (což s tím FS nepůjde, protože by se muselo všechno postahovat k tobě).

Jinak samozřejmě bude narážet na to, že se rychlý jednorázový clone na začátku mnohonásobně vrátí ve výrazně pomalejších běžných operacích při vlastní práci.

Tohle je jedna z velkých výhod distribuovaných verzovacích systémů a MS se tak vrací o víc než deset let zpátky.

U toho use case, který tam popisují (kompletní codebase Windows, 3.5 milionu souborů, 270 GB) mi ale připadá, že zásadní chyba je už v tom, že to potřebují mít všechno v jednom repozitáři.

+1 je to pořádný hnůj. Tohle mělo být jednoznačně modularizované a rozdělené do více malých repozitářů.

[Michal Kubeček]

Na občasné nahlédnutí jsou různé webové UI – které ti navíc můžou nabídnout i rychlé hledání (což s tím FS nepůjde, protože by se muselo všechno postahovat k tobě).

Tam jsem ale omezen tím, co to webové UI nabízí. Nevzpomínám si třeba, že bych viděl webové UI ke gitu, které by umělo ekvivalent "git blame".

Tohle mělo být jednoznačně modularizované a rozdělené do více malých repozitářů.

Nebo aspoň do více velkých. :-)

[xkucf03]

Tam jsem ale omezen tím, co to webové UI nabízí. Nevzpomínám si třeba, že bych viděl webové UI ke gitu, které by umělo ekvivalent "git blame".

Měl jsem za to, že tohle je běžná vlastnost. Mercurial to umí v základu (to výchozí webové rozhraní resp. server), jmenuje se to annotate. U gitu používám Kallitheu a tam je taky funkce Show Annotation.

[Sten]

GitLab, Gitorious, Bitbucket umí blame out-of-box. U gitwebu je potřeba blame zapnout v konfiguraci.

[Josef Kufner]

Nevzpomínám si třeba, že bych viděl webové UI ke gitu, které by umělo ekvivalent "git blame".

Příklad: https://gitlab.com/gitlab-org/gitlab-ce/blame/1e97a6df24f66f70811fdd4b1412432e40ab8ebe/README.md

[gze]

Takže když na to přejdu (což nehrozí) a bude další výpadek gitlabu, tak budu v pytli úplně

[Spitzbube]

[J]

Rozumiem ze z povahy NTFS moze byt praca s git ovela pomalsia ako na Linux. Ja som myslel ze riesia toto a nie prenos po sieti :) Vsak princip cislo 1 je mat po clone na lokali cele repo :D a je jedno ci to pojde 12 hodin alebo minut

[Kvakor]

Neřekl bych, že za to může NTFS jako souborový systém, spíš bych řekl, že jde o způsob, jak s ním Windows pracují, respektive jak dobře či špatně cachují jak datové bloky, tak už načtené informace o souborech a adresářích.

Když jsem před delší dobou zkoušel multiplatformní program (no, dělal jsem ho na Linuxu, ale byl přenositelný díky použití SDL), co používal řádově stovky tisíc souborů (ale rozstrkaných do adresářů, kde v jednom nebylo více než stovky položek), tak na stejném disku/souborovém systému (NTFS, v Linuxu připojený přes FUSE NTFS-3G) a stejněm stroji s dualbootem (Debian 7.něco versus Win7 64bit) byla rychlost přístupu k souborům o něco rychlejší v Linuxu (minimálně kotrolka disku méně blikotala), i za cenu poněkud větší zátěže CPU (za to ale nejspíš mohlo hlavně FUSE). Jako hlavní důvod bych typoval právě lepší využití cache, jak na úrovni bloků, tak adresářů - u Windows jsem měl pocit, že zbytečně zahazují už nacachované položky i když mají ještě dost volné paměti (stroj měl 4GB a v obou OS nikdy neukazoval využití víc než poloviny).

PS: Několikát jsem četl, že tuto "zbytečnou škudlivost" ohledně využití RAM jako diskové cache Microsofti už opravili ... mám pocit, že ve Win7 to udělali nanejvíš jen z části, možná až ve Win8/10, ale v těch jsem nic testovat nezkoušel (a dělat něco takového jen tak by mi připadalo příliš masochistické ).

[j]

To nema nic spolecnyho ani s widlema ... pro widle axistujou appky tretich stran, ktery s filesystemem pracovat umej. Zkus si ve widlich otevrit folder ve kterym sou desitky tisic souboru ... a pose... se z toho. Ale existujou appky, ktery ti uplne klidne behem par vterin vylistujou vsechny soubory z celyho disku. Na presne stejnejch widlich. To jen v M$ proste neumej napsat vubec nic tak, aby to i fungovalo.

[biolog]

Otevřít folder jako v čem? V Průzkumníku? Tak to bývá tím, že je na tom Windowsu nainstalovaná nějaká úžasná aplikace s rozšířením do Průzkumníka. Kolega nainstaloval něco na firemní server, a člověk skoro ani nemohl procházet svůj profil.

[ES]

Napriklad jaky? kopirovani hodne dat pod woknama je des. Za to klidne i zaplatim.

[kralyk z abclinuxu]

Trochu rovnáky na vohejbáky, ne?

Tohle řešíme btrfs/zfs snapshoty, napoprvé si repo vyklonuju někam k sobě do subvolumu, nechám ho nedotčený (pouze aktualizuju) a kdykoli chci něco dělat, vytvořim snapshot/clone vedle, což je levný a update je taky levnej.

(Je ale pravda, že ty jejich repa jsou ještě o dost větší, nicméně principielně je to totéž, stačí mít dostatečně velkej disk.)

[Filip Jirsák]

A když použiješ git worktree, nepotřebuješ ani ty klony a snapshoty a můžeš mít několik pracovních adresářů s jedním repository.

[kralyk z abclinuxu]

git worktree znám, ale tenhle projekt používá Mercurial. Nicméně, i kdyby to byl git, je vytvoření worktree stejně levné jako klon v ZFS? Klon 2GB hg repo je se ZFS vytvořen téměř instantně.

Další výhoda ZFS/Btrfs jsou snapshoty, např. vždy, než dělám nějakej složitější rebase, nejprv vytovřim snapshot, takže když ten rebase nějak zvořu nebo se něco nějak pokazí, můžu rollbackovat (opět téměř instantní operace) na stav před.

[Sten]

Je ještě levnější, protože object store není sdílený přes COW, ale přímo, takže repack a pull nevytváří nové kopie.

Rollback rebase se dělá pomocí git reset.

[kralyk z abclinuxu]

Je ještě levnější, protože object store není sdílený přes COW, ale přímo, takže repack a pull nevytváří nové kopie.

Object store mě nijak netrápí, úzké hrdlo je vytvoření novýho pracovního adresáře. Pokud tomu dobře rozumim, git worktree add musí udělat checkout repo do novýho adresáře - v podstatě tam vytvořit celý adresářový strom a nakopírovat všechny data. Děkuji, nechci.

Rollback rebase se dělá pomocí git reset.

Tak jasný, ono to obvykle stačí, ale když dělám nad repo něco divočejšího, je fajn mít to zajištěno na jiné vrstvě.

[kralyk z abclinuxu]

Jo a ještě další věc: Ten vanilla repozitář se updatuje skriptem z cronu, který zároveň potom spouští build (někdy v noci), takže když si pak následující den repo naklonuju a něco změnim, stačí většinou už jen inkrementální build, který je pochopitelně mnohem kratší.

[Sten]

Nad Btrfs tu kopii dělá pomocí reflink (COW), u ZFS nevím, jestli je reflink podporován.

[Vantomas]

Ale je hezké, že Microsoft začal pro svoje potřeby používat git. Ať byl nebo je Microsoft jakkoliv zlý, ve chvíli, kdy mu vývojáři začnou používat opensource nástroje, tak se chtě nechtě změní pohled a chování všech lidí ve firmě k opensource. A z toho opensource svět může jenom těžit.

[xvasek]

Příští build Windows se chystá přes mingw/gcc.

[ehmmm]

Taky me to prekvapuje. Jsem myslel, ze Microsoft musi pouzivat TFS. (?)

[xyz]

TFS git umí a je dokonce používanější než TFVC.

[podlesh]

Jo, už nějakou dobu. Je docela zábavné sledovat na různých fórech jak z toho skalní fanoušci Microsoftu dostávají vyrážku. Vlastně, většinou už bývalí skalní fanoušci (i když mnoho jich stále zůstává věrno a trpělivě čeká na návrat starých časů).

[Jardik]

Něco takového jsem už někde viděl, ale nemůžu si vzpomenout, kde.

[x]

ClearCase, ale ten alespon funguje i na Linuxu.

[Mti.]

bleh...

#dnf list | grep -i gvfs | wc -l
18

...tak doufam, ze se to bude jmenovat jinak, nez to Poeterring zacleni do systemd :/

[Josef Kufner]

Pokud je repositář velký kvůli historii, tak stačí git clone --depth 1. Pokud je potřeba práce s velkými soubory, máme LFS.

[Dreit]

https://github.com/PressLabs/gitfs

[AAA]

Nojo, ale jestli to chapu dobre gitfs od PressLabs dela commity automaticky za tebe pri kazde zmene souboru.

[pc2005]

Proč by měl buildroot stahovat kompletní git repo všech stovek programů OS? Však stačí zabzipovaný stable snapshot.

[Peter Golis]

Pretože môže.

[kamen]

jezismarja C#

[AAA]

Trocha svetla na to proc maji jeden velky git repozitar (z diskuze z odkazu):

Matt Kerr

“The first big debate was – how many repos do you have – one for the whole company at one extreme or one for each small component? A big spectrum. Git is proven to work extremely well for a very large number of modest repos so we spent a bunch of time exploring what it would take to factor our large codebases into lots of tenable repos. Hmm. Ever worked in a huge code base for 20 years? Ever tried to go back afterwards and decompose it into small repos? You can guess what we discovered. The code is very hard to decompose. The cost would be very high. The risk from that level of churn would be enormous. And, we really do have scenarios where a single engineer needs to make sweeping changes across a very large swath of code. Trying to coordinate that across hundreds of repos would be very problematic.” https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-story/

[Michal Kubeček]

To není žádné velké překvapení, bylo asi celkem jasné, že tahle chyba nevznikla při přechodu na git, ale dávno předtím.

[xvasek]

Takže to dělají blbě a ještě se k tomu drze přizná. Následné řešení na způsob MS je jasné - udělat k tomu klikací GUI nástroj v .netu a obohatit jeho výjimečností tady ten repozitář.

[koudy]

Šmarjá, mě se udělalo nevolno...

To bych nechtěl spravovat, udržovat ani v tom něco psát...

Win10 vypadají až neskutečně dobře, pokud vezmu v potaz z čeho to vzniká. :D

[Sten]

Možná by jim někdo mohl poradit, že přesně to samé dělá repo v Androidu. Ale jestli mají podobnou metodiku jako Google, kde přehrabování se v repozitáři = nula pracovních bodů, zatímco nový projekt = spousta pracovních bodů, tak celkem chápu, proč si zvolili tohle.

[Maxmilian Prdel]

Jenze ono nejde jen o repozitar. Kompletni build Windows je na zhruba 15 iteraci, protoze po castech to kompilovat taky nejde a vyvojari pisou kod naslepo (a pak to kompilatorem proste neproleze). Spetky stability finalnim releasum Windows dodava armada Indu, ktera oklikava stale tytez scenare a reportuje jakekoliv odchylky. Udajne jeden Ind dokaze oklikat zhruba 900 scenaru za den. Pak se kazda chyba vraci zpatky do MS, kde se snazi uhodnout, cim vznika, a cele se to znovu opakuje. Kdyz se blizi deadline a nejsou opravene vsechny chyby (tzn. pokazde), tak se ty "nejmene zavazne" (coz je vse, co nezpusobuje vyslovene nefunkcnost nebo ztratu dat) proste ignorujou a opravuje se to pak v aktualizacich. Z toho taky vzniklo rozhodnuti, ze Windows 10 bude posledni verze a nadale se bude jen aktualizovat. Oni proste nejsou schopni to dal rozumne vyvijet. Shodou nahod mi zrovna dnes kolega po dotazu, co dela, rekl: "Just this bugfix... was supposed to ship with XP, but you know.. ain't no time.".

Research vyvojare, kam ted cerstve posledni ~3 mesice spadam i ja, Microsoft umi dobre zaplatit (+ davaji uz v prvnim roce vic nez 2 tydny dovolene, coz se v US vidi velmi zridka, a predevsim sami zarizujou veskera viza a pozdeji pomuzou i s green card), a lze se dostat k zajimavym vecem. Nas tym pracuje na prototypu bytecode-based operacniho systemu, kde krome VM zpracovavajici MSIL nebude zadny nativni kod. Dal se to toci vesmes okolo cloudu, tzn. hodne inspirace cerpame z Plan9. V idealnim pripade proste chteji soucasny Windows zahodit a vsechno vcetne UI prevest pod .NET. Takze asi tak.

[xvasek]

Hele, můžu položit otázku - a neber ji prosím nijak útočně.

Myslíš, že něco jako úplně nový OS, který budou normálně lidi využívat, je MS schopný v příštích deseti letech vytvořit a vydat?

[Maxmilian Prdel]

Jo. Zacinalo se v lednu a ta vyzkumna faze se planuje na 5 let, pak dalsi 3 roky uvedeni do praxe. Ted nejak zvolna zaciname psat kernel, ktery zvladne zakladni obsluhu vybraneho HW. V MS jsou lidi, co 10+ let spravujou jen sitovej nebo USB subsystem, takze tohle neni vubec problem. Trochu vic abstraktni veci jako jsou drivery pro FS uz budou napsane high-level v C# a pres JIT zkompilovane do nativniho kodu. Jako FS se asi pouzije ext4, konecne rozhodnuti jeste nepadlo.

Jo a BTW, vymyslel to Nadella, takze by to do produkce melo jit jako open-source (jeste se nevi license). Ono MS to v podstate vnima tak, ze na desktopech se uz vydelat neda (neda se konkurovat treba Ubuntu), ale chteji vydelavat na Azure a chteji tedy OS, ktery bude z cloudu umet dobre profitovat... A nebo na cem budou schopni provozovat svoje servery. Aby to umelo za behu presouvat programy mezi serverama, sdilet RAM po siti, a tak. Taky z toho prameni codename Azure OS.

[pc2005]

Uf a to jsem si stěžoval, že trvá dlouho přijímání patchů do kernelu .

Nas tym pracuje na prototypu bytecode-based operacniho systemu, kde krome VM zpracovavajici MSIL nebude zadny nativni kod.

Nechtěli tohle udělat ve Vistách? BTW blé další android.

[ehmmm]

Taky si myslim, ze uz jednou neco jako "Windows v .Netu" zkouseli. Druha super vlastnost mel byt souborovy system jako databaze, ale oboji pak zrusili. (?)

[Maxmilian Prdel]

Jj, uz se neco zkouselo. Ballmer to utnul.

[agio]

https://cs.wikipedia.org/wiki/WinFS

[Michal Kubeček]

že trvá dlouho přijímání patchů do kernelu

Záleží na subsystému (resp. maintainerovi). :-)

[pc2005]

To je pravda jeden můj patch na webkameru musel začlenit až úplně někdo jinej .

Ale třeba diskuze o spojení hwmon/thermal byla taky vtipná. Skoro každý driver může mít ve jménu pomlčku, ale libsensors tu pomlčku používá pro oddělovaní atributů ... změna libsensors by byla změna ABI, náhrada za podtržítko taky, ale přidání ".auto" stringu do jména nikomu nevadilo. Nakonec prej to spojení jmen revertli .