Microsoft propose GVFS, un système de fichiers open source accélérant les opérations Git

Des fichiers déshydratés

Le 06 février 2017 à 15h00

4 min

Logiciel

Microsoft propose depuis ce week-end un système d’extension open source dédié aux dépôts Git. Nommé GVFS, il est proposé à la communauté et ambitionne d’accélérer très nettement certaines opérations en virtualisant les ressources.

GVFS, Git Virtual File System, est un projet de Microsoft sous licence MIT. Il est disponible depuis peu dans un dépôt Git, l’éditeur espérant fédérer une communauté de développeurs autour d’un objectif bien précis : rendre les opérations Git bien plus rapides sur les dépôts de projets contenant des millions de lignes de code.

La problématique des très gros projets

Microsoft articule ses explications autour d’un exemple emblématique : Windows. Le code source du système (on imagine que l’éditeur parle de la version 10) s’étale en effet sur pas moins de 3,5 millions de fichiers, contenant chacun un nombre indéfini de lignes de code. En tout, cette montagne de données fait son poids : la bagatelle de 270 Go.

Or, Microsoft indique que s’il apprécie particulièrement Git, le système de gestion de versions voit ses performances dégradées dans le cas de très gros projets. Toujours sur l’exemple de Windows, un « checkout » peut prendre ainsi jusqu’à 3 heures, un « clone » plus de 12 heures et même un simple « status » peut durer jusqu’à 10 minutes.

On notera que Gabriel Aul, qui dirigeait auparavant le programme de test Windows Insider, participe également au projet. Il indique dans un tweet que Microsoft transfère actuellement son SCM (Source Code Management), ce qui explique les travaux réalisés dans le même temps, l’éditeur souhaitait avant tout répondre à ses propres contraintes.

Un système de fichiers virtualisé

GVFS virtualise en fait le système de fichiers sous-jacent au dépôt. Il laisse apparaître tous les fichiers comme s’ils étaient bien là, mais ne les récupère en réalité que lorsqu’un utilisateur cherche à l’ouvrir pour la première fois. Un fonctionnement qui offre selon Microsoft plusieurs avantages, notamment l’absence de modification dans les environnements de développement et les différents outils de compilation.

Le principal, ce sont évidemment les performances de ce système quand il faut lancer des commandes Git. « clone » ne nécessiterait ainsi plus que quelques minutes au lieu d’une douzaine d’heures, un « checkout » environ 30 secondes au lieu de deux à trois heures, et un « status » quatre ou cinq secondes au lieu de dix minutes. L’éditeur insiste d’ailleurs : il ne s’agit que d’un premier jet, et il est possible de faire encore mieux.

Pour comprendre le fonctionnement de GVFS, il faut aborder le concept « d’hydratation ». On parle d’un fichier « hydraté » quand une coquille quasiment vide existant en mémoire est remplie avec des données réelles. L’évocation de ce fichier devient alors le fichier à proprement parler. Or, c’est là le mécanisme central de GVFS. Les opérations ne s’exécutent que sur des fichiers « hydratés », puisque les autres correspondent à des données qui n’ont pas été utilisées récemment.

For those who ask what I've been working on, here's a bit. We're moving our SCM to Git and invented a bit of tech: https://t.co/rQdcOx6wI5

— Gabriel Aul (@GabeAul) 3 février 2017

Ne reste qu'à motiver la communauté autour du projet

Ce fonctionnement correspond selon Microsoft à l’utilisation faite de Git en général : « Dans un dépôt aussi imposant, aucun développeur ne compile l’arbre entier des sources. Au lieu de ça, ils téléchargent généralement les dernières modifications depuis la plus récente build et ne compilent alors qu’une petite partie des sources, liées à ce qu’ils ont modifié. Donc même s’il y a plus de trois millions de fichiers dans le dépôt, un développeur typique n’aura besoin que de télécharger et utiliser 50 000 à 100 000 de ces fichiers ».

Évidemment, il y a peu de chances que les développeurs aient des dépôts aussi vastes, mais le gain de temps peut être manifeste et le projet est sous licence MIT. Reste à voir si la communauté répondra présente. Tous ceux qui se penchent sur GVFS pourront se rendre sur le dépôt Git du projet, qui contient d’ailleurs toutes les instructions d’installation. Cette dernière passe par l’utilisation d’un pilote spécifique, qui demandera de désactiver momentanément BitLocker pour être mis en place.

Accéder au dépôt de GVFS sur GitHub

Commentaires (80)

bagofgnutea

Le 06/02/2017 à 16h46

On est pas dredi mais

 Par ce que tu a déjà vue un windows rapide toi ?

 

127.0.0.1

Le 06/02/2017 à 16h46

“In addition to the GVFS sources, we’ve also made some changes to Git to allow it to work well on a GVFS-backed repo, and those sources are available at GitHub

“And lastly, GVFS relies on a protocol extension that any service can implement; the protocol is available at GitHub”
1. Tout ce que je dis, c’est que Ms font ces améliorations d’abord et surtout pour leurs besoins spécifiques et personnels. Même si, au final, la communauté en profitera (merci a eux). Ce n’est pas du bashing gratuit, c’est juste une constatation: 99.9% de la communauté ne gère pas des mega-repositories.

Bejarid

Le 06/02/2017 à 16h54

bagofgnutea a écrit :

On est pas dredi mais

 Par ce que tu a déjà vue un windows rapide toi ?

 

Sur mon PC actuel ouais. Pas sur mon serveur ceci-dit, pour une machine à base d’Atom je suis revenu sur un linux, windows server est un peu trop gourmand (peut-être le cache processeur qui n’est pas assez gros, je sais pas mais ça tournait moyen, j’imagine qu’avec les nouvelles versions Nano ça pourrait mieux marcher).

Et sinon, la Sword elle a fini de rouiller, il n’en reste plus que de la poudre d’oxide de fer ? :(

sdesbure Abonné

Le 06/02/2017 à 17h00

pour ton 1), le kernel Linux gère lui aussi beaucoup de drivers (et peut être même plus que windows…). Pourtant il ne fait “que” 800Mo (soit ~300 fois moins), sachant qu’il a démarré il y a 25 ans donc bon…

Le “truc” c’est que windows c’est le kernel Linux + la glibc + x.org + qt + KDE (ou un autre ;)) + konqueror + kalc + …

 Et ce qu’il disent c’est que tout est super imbriqué.

Après peut être qu’il vont au fur et à mesure désimbriquer certaines parties (je pense que la calculatrice doit pouvoir être un projet à part entière facilement ;) ) et ils auront moins de super repos mais pour le moment c’est trop compliqué.

J’y vois en tout cas un avantage de l’open source qui a permis d’avoir des repos à taille humaine (enfin, KDE c’est quand même 21M de lignes de code mais explosé en 300 projets)

Bejarid

Le 06/02/2017 à 17h10

sdesbure a écrit :

Après peut être qu’il vont au fur et à mesure désimbriquer certaines parties (je pense que la calculatrice doit pouvoir être un projet à part entière facilement ;) ) et ils auront moins de super repos mais pour le moment c’est trop compliqué.

Pour l’exemple de la calculatrice, je pense que c’est fait sur Win10 puisque c’est une app windows store maintenant. Mais y a beaucoup d’autres choses qu’ils ne peuvent pas trop toucher sans casser plein d’appli (grand public, ou pire, spécifique dans les entreprises).

D’un coté MS a envie de sortir régulièrement de nouveau windows (ou de le faire évoluer) et d’un autre coté les gens veulent que leur anciens logiciels non maintenu continue de fonctionner. Compliqué comme équation.

OlivierJ Abonné

Le 06/02/2017 à 17h11

Bejarid a écrit :

Le pire, c’est que t’es surement convaincu de ce que tu dis. C’est fou.

Je t’invite à lire ce que j’ai écrit juste avant en #39.

Ce n’est pas du “MS-bashing” c’est lié à la conception.

bagofgnutea

Le 06/02/2017 à 17h14

–Sur mon PC actuel ouais.–

Si tu le dit jte croi :)

On commence a voir ça de plus en plus non pas par ce que windows devient bon.

mais par ce que les drivers sont mieux développer du a l’unification des windows (prochainement disponible windows 10 cloud).

Perso si tu compare xp a windows 10 il y a un gouffre en terme de performance (en terme de sécu aussi) mais bon est ce comparable ?

On continuera a voir ce de différence temps que les constructeurs de matériels ne donneront pas les manuels de leur hardware.

Sinon sur ta machine perso tu est sure d’avoir compiler le kernel correctement ?

Un nextimpactient avais fais un très bon tuto la dessus

voila le lien

OlivierJ Abonné

Le 06/02/2017 à 17h52

bagofgnutea a écrit :

Sinon sur ta machine perso tu est sure d’avoir compiler le kernel correctement ?

Un nextimpactient avais fais un très bon tuto la dessus

voila le lien

Pour avoir besoin de compiler soi-même le kernel, il faut des besoins bien spécifiques. Je l’ai fait au tout début il y a très longtemps, mais ça fait longtemps que je n’ai plus eu à le faire, ceux des distributions conviennent.

jinge

Le 06/02/2017 à 18h41

Moi ça me fait penser au système utilisé par onedrive. Ca a du bon et du mauvais: l’avantage de la copie locale c’est qu’en cas de pépin on a un backup. Mais d’un autre coté ça permet de faire économiser beaucoup de place!

 

arno53

Le 06/02/2017 à 18h41

Pour ton point 2 c’est la base du libre non ? Les ingénieurs Intel faisant des comits sur Linux ne le font pas pour améliorer le support d’ARM ou des processeur AMD..

Et aujourd’hui Linux n’est pas développé par 3 gus dans un garage mais justement par des multinationales qui voient leurs intérêts avant tout..

bagofgnutea

Le 06/02/2017 à 18h41

Définie moi “besoin spécifique” ^^

j’utilise gentoo en dehors de trisquel donc “besoin spécifique” pour moi c’est “si j’utilise pas il a rien a faire ici”

Sinon j’ai bien compris ton message ;)

Passe une bonne soirer.

bagofgnutea

Le 06/02/2017 à 18h44

–qu’il faut certainement un lien constant avec un serveur central.

–

Vue que Microsoft va vers le cloud (windows 10 cloud) c’est pas étonnant.

jinge

Le 06/02/2017 à 18h45

jcdr a écrit :

Le code d’un noyau Linux prend actuellement environ 800Mo avec environ 60’000 fichiers et même sur mon vieux AMD A10-7850K il ne faut que 0.5 secondes pour faire un git status ou un git diff sur tout le code. A priori même avec un code délirant de 270Go ça ne devrait pas prendre tellement plus de 3 minutes. Délirant car ça semble difficile de croire qu’il ne soit pas possible d’organiser autant de données dans de multiples sous-projets, une possibilité qui est maintenant très bien supportée par Git. Il doit y avoir un sérieux problème historique d’organisation des données…

Finalement il faut rappeler ici que Git a pour but principale de pouvoir fonctionner de façon totalement décentralisée, ce qui implique une copie complète locale du dépôt. Il y a quelques possibilités pour augmenter les performances en limitant le transfert initial, mais cela peut demander des transferts ultérieurs. La proposition de Microsoft semble miser beaucoup sur cette technique mais la conséquence est qu’il faut certainement un lien constant avec un serveur central.

Pour les 270Go tu ne peux pas comparer le système d’exploitation au noyau (Le framework .Net c’est beaucoup moins par exemple). Windows il y a aussi windows server, probablement office?, visual studio et toutes les suites logicielles que MS a développé (enfin sinon ça parait effectivement beaucoup, même s’il doit y avoir beaucoup plus de commentaires que de code maintenant!).

Pour la copie locale, je suppose que tu peux forcer la copie de certains dossiers… 

anastra

Le 06/02/2017 à 19h58

Je veux pas dire une connerie mais le système est semblable a se qui existé avec OneDrive avec les fichiers coquille quasiment vide. Mais avec Windows 10 il l’on retiré :(

 

Arimane

Le 06/02/2017 à 20h36

Bejarid a écrit :

 D’après ce que j’ai compris, le problème de portage serait les interactions GVFS-Kernel-FileSystem.

Ils ont dev leur truc en s’appuyant sur les API Windows et NTFS, qui permet quelques blagues de ce coté là afin d’avoir de bonne perf. C’est pas dit que ça pourrait s’appliquer tel quel aux autres systèmes, faudrait potentiellement changer le fonctionnement, ou ouvrir de nouvelles portes.

Tout un programme.

En même temps c’est sous licence MIT donc rien n’empêche une batterie de devs motivés de faire un portage. Microsoft fait des efforts pour aller dans le bon sens en publiant leurs travaux vers la communauté, ne soyons pas trop sarcastiques…

zefling Abonné

Le 06/02/2017 à 20h38

127.0.0.1 a écrit :

helloworld.c –> 63 octets

helloworld.exe –> 6300 octets

" />

Je ne suis sûr que ceux qui font des demo 4k ait juste 40 octects de code. " />

Exemple :http://www.pouet.net/prod.php?which=67971

Édit : il y a même du 32 bytes http://www.pouet.net/prodlist.php?type[]=32b

127.0.0.1

Le 06/02/2017 à 15h06

GIT étant conçu comme un système de fichiers (dixit Linus Torvalds), l’effort technique n’est pas énorme.

Quand à la virtualisation (=hydratation à la demande) , c’est pas non plus révolutionnaire pour tous les admins qui ont connu les sauvegardes sur bandes.

Bref, une très bonne idée de Ms de proposer ce GVFS, mais rien d’exceptionnel question ingénierie.

Le “we invented a bit of tech” est un peu “too mutch”, de mon point de vue.

levhieu

Le 06/02/2017 à 15h08

Sinon, pour les grosses bases de logiciel, il y a repo.

Évidemment, pour Microsoft, il y a 2 inconvénients:

C’est fait par google

Il faut que les projets agglomérés dans le gros machin soient bien découp(l)és

fred42 Abonné

Le 06/02/2017 à 15h08

Est-ce que ce système de fichier est/sera disponible sous Linux ?

Nota : Ceci n’est pas un troll.

brazomyna

Le 06/02/2017 à 15h09

le problème initial, ce ne serait pas d’avoir un dépôt Git unique pour 3,5 millions de fichiers ?

Y’avait pas moyen de subdiviser un peu les choses, justement pour ne pas tomber dans ce genre de cas limite ?

Strimy

Le 06/02/2017 à 15h12

Tu peux lire cette article de blog pour avoir un aperçu un peu plus complet des raisons qui les ont fait choisir Git :https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-sto…

(A noter que Microsoft n’est pas le seul à fonctionner avec un énorme repository, Google semble faire de même)

Jarodd Abonné

Le 06/02/2017 à 15h12

Haken Trigger

Le 06/02/2017 à 15h13

Nécessite InnoSetup, qui est disponible uniquement pour Windows il semblerait.

Sinon bonne idée de leur part, même si des projets aussi énormes ça court pas les rues. Et moins je dépends de Google (repo), mieux je me porte ! " />

Strimy

Le 06/02/2017 à 15h16

Jarodd a écrit :

Rien compris " />

En gros, le fichier qui est visible est un fantôme, il ne prend pas de place. Par contre, au moment où tu essaies de l’ouvrir, son contenu est récupéré de manière transparente. (si t’as utilisé OneDrive sur Windows 8, il y avait le même système)

brazomyna

Le 06/02/2017 à 15h19

Strimy a écrit :

Tu peux lire cette article de blog pour avoir un aperçu un peu plus complet des raisons qui les ont fait choisir Git :https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-sto…

(A noter que Microsoft n’est pas le seul à fonctionner avec un énorme repository, Google semble faire de même)

Ma remarque n’avait pas pour objet de remettre en quesiton le choix de git, mais le fait d’avoir un seul énorme rpository plutôt que plusieurs centaines de repositories plus petits.

Bamaury

Le 06/02/2017 à 15h21

Cool

OlivierJ Abonné

Le 06/02/2017 à 15h21

Le code source du système (on imagine que l’éditeur parle de la version 10) s’étale en effet sur pas moins de 3,5 millions de fichiers, contenant chacun un nombre indéfini de lignes de code. En tout, cette montagne de données fait son poids : la bagatelle de 270 Go.

Si ces chiffres sont exacts, c’est gigantesque " /> . Comment ils font, alors qu’on parle juste de l’OS ?

(cela dit ça ne m’étonne pas trop que ce soit un peu le b*rdel chez eux, quand on a connu le style de codage de Redmond dans le temps (non, pas un troll))

NB : on peut comparer à Linux, qui en plus tourne sur un nombre d’architectures impressionnant, et sachant que les drivers sont dedans et prennent une grosse place.

127.0.0.1

Le 06/02/2017 à 15h21

C’est comme si tous les fichiers faisaient “zéro octet” tant que tu n’as pas besoin d’accéder au contenu.

Des que tu accèdes au contenu, le fichier est réhydraté (rempli avec son contenu).

Du coup, toutes les opérations de gestion (duplication, déplacement, navigation …) se font sur très peu de volume.

tifounon

Le 06/02/2017 à 15h21

C’est comme le bolino.

T’as juste l’essentiel, et quant tu rajoutes de l’eau au fur et à mesure ça prend du volume.

tifounon

Le 06/02/2017 à 15h23

Non c’est pas étonnant, le code source est toujours plus gros que le code compilé.

J’ai toujours vu ça du moins.

white_tentacle Abonné

Le 06/02/2017 à 15h24

Ça peut être assez chiant de devoir gérer beaucoup de repo différents, en terme d’administration, et tout ça.

Sinon, ils ont conscience que gvfs c’est gnome virtual filesystem, et que reprendre le nom ça va juste rajouter de la confusion si jamais leur truc arrive sous linux ?

Strimy

Le 06/02/2017 à 15h24

C’était justement dans ce sens là que je te donnais ce lien " />

Les choix sont indiqués, et ils parlent des pistes qu’ils ont envisagé.

alex.d. Abonné

Le 06/02/2017 à 15h27

On voit qu’ils ne connaissent pas du tout la communauté open source chez Microsoft. GVFS, c’est déjà pris comme nom…

 

spidermoon

Le 06/02/2017 à 15h29

OlivierJ a écrit :

Si ces chiffres sont exacts, c’est gigantesque " /> . Comment ils font, alors qu’on parle juste de l’OS ?

(cela dit ça ne m’étonne pas trop que ce soit un peu le b*rdel chez eux, quand on a connu le style de codage de Redmond dans le temps (non, pas un troll))

NB : on peut comparer à Linux, qui en plus tourne sur un nombre d’architectures impressionnant, et sachant que les drivers sont dedans et prennent une grosse place.

Pas étonnant, un simple Angular2 webpack starter c’est déjà 20 400 petits fichiers et 3 000 dossiers. Et c’est ça qui prend un temps fou à lire/écrire, à moins d’avoir un raid de SSD.

127.0.0.1

Le 06/02/2017 à 15h30

helloworld.c –> 63 octets

helloworld.exe –> 6300 octets

" />

emersion

Le 06/02/2017 à 15h37

Non justement, ça a demandé du boulot, au point qu’ils ont du créer une extension de l’API HTTP de Git.

D’ailleurs, du coup ça ne marche que sur les serveurs Git qui supportent gvfs.

AxS

Le 06/02/2017 à 15h38

Passer à un système de fichiers virtuels, ça casse pas l’interet de GIT d’être un système distribué ?

Parce que du coup les fichiers restent sur le dépot central, et ne sont rappatriés qu’au besoin réel.

Si le répo central tombe ou n’est plus accessible, le dev est bloqué.

Et si ce répo est définitivement perdu…

Bejarid

Le 06/02/2017 à 15h39

OlivierJ a écrit :

Si ces chiffres sont exacts, c’est gigantesque " /> . Comment ils font, alors qu’on parle juste de l’OS ?

(cela dit ça ne m’étonne pas trop que ce soit un peu le b*rdel chez eux, quand on a connu le style de codage de Redmond dans le temps (non, pas un troll))

NB : on peut comparer à Linux, qui en plus tourne sur un nombre d’architectures impressionnant, et sachant que les drivers sont dedans et prennent une grosse place.

A parce que Windows contient pas de drivers peut-être ? :p

Et Windows, ce n’est qu’un kernel peut-être, y a pas 25 milles outils embarqué en plus dans le bouzin ? :p

Y a pas mal de soft de MS qui sont gigantesques en termes de lignes de codes, et ce n’est pas étonnant, leurs soft ont tellement de fonctionnalités dans tous les sens… Certaines sont dev juste pour une seule entreprise cliente, et quand on met ça en perspective avec le nombre de clients de MS, ça devient tout de suite plus logique, les centaines de Go de code !

Visual Studio aussi est un monstre de plusieurs millions de ligne de code par exemple, il est comparable à la taille de WinXP. Pourtant ce n’est “qu’un” IDE.

Sauf qu’il fait aussi plein de truc super spécifique pour plein de cas tordus ^^

AxS

Le 06/02/2017 à 15h39

Et suivant les cas ça peut même etre très chiant -> cf les submodules.

Une seule répo a ses abantages…

Bejarid

Le 06/02/2017 à 15h43

Haken Trigger a écrit :

Nécessite InnoSetup, qui est disponible uniquement pour Windows il semblerait.

 D’après ce que j’ai compris, le problème de portage serait les interactions GVFS-Kernel-FileSystem.

Ils ont dev leur truc en s’appuyant sur les API Windows et NTFS, qui permet quelques blagues de ce coté là afin d’avoir de bonne perf. C’est pas dit que ça pourrait s’appliquer tel quel aux autres systèmes, faudrait potentiellement changer le fonctionnement, ou ouvrir de nouvelles portes.

Tout un programme.

OlivierJ Abonné

Le 06/02/2017 à 15h58

tifounon a écrit :

Non c’est pas étonnant, le code source est toujours plus gros que le code compilé.

J’ai toujours vu ça du moins.

Oui mais ça ne change rien à ce que je dis.

alex.d. a écrit :

On voit qu’ils ne connaissent pas du tout la communauté open source chez Microsoft. GVFS, c’est déjà pris comme nom…

Clairement : Wikipedia(G = GNOME).

spidermoon a écrit :

Pas étonnant, un simple Angular2 webpack starter c’est déjà 20 400 petits fichiers et 3 000 dossiers. Et c’est ça qui prend un temps fou à lire/écrire, à moins d’avoir un raid de SSD.

" />

C’est des mecs de chez MS qui ont codé ça ?

127.0.0.1 a écrit :

helloworld.c –> 63 octets

helloworld.exe –> 6300 octets

" />

Arf mais là c’est normal, c’est le cas de tous les tous petits programmes, il y a les bibliothèques de base qui sont liées, dont celle qui permet par exemple d’analyser les arguments (argc/argv), et le nettoyage sur “exit()” même implicite.

ErGo_404

Le 08/02/2017 à 08h44

Dément mais pas étonnant. Le code source contient toutes les ressources (images, vidéos, etc), beaucoup beaucoup beaucoup de texte non compressé, etc. Probablement le code des outils qui servent à builder l’OS, à tester chez les partenaires, à générer des mises à jour, et des milliers de choses qu’on ne connaît pas.

Non à vrai dire ça ne m’étonne pas, ça monte très vite le nombre de lignes de code quand on documente proprement ce qu’on fait.

zethoun

Le 08/02/2017 à 11h07

neojack a écrit :

apres toutes ces années il n’y a eu aucun dev indelicat pour faire un git clone sur son ordi, un coup de winrar, et passer le tout sur piratebay ?

et un putain de procès de la part de MS qui va l’endetter lui et toute sa famille (cousins germains compris ^^) sur 100 générations? :p

OlivierJ Abonné

Le 08/02/2017 à 17h53

Pas 2 Go, pas 27 Go (punaise déjà ce serait bien gros), mais DEUX. CENT. SOIXANTE. DIX. GIGAS…

J’arrive pas à piger, mais je m’en remettrai :-) .

Je vois une explication éventuelle, c’est qu’ils gardent toutes les révisions hebdomadaires depuis des années, ça doit bien faire enfler.

ErGo_404

Le 08/02/2017 à 20h46

Rien n’indique qu’il n’y a qu’un seul OS. D’ailleurs on peut lire sur d’autres sites qu’ils ont tous les Windows dans le même repo.

Et il y a un paquet de versions Windows…

jcdr

Le 08/02/2017 à 22h26

OlivierJ a écrit :

Pas 2 Go, pas 27 Go (punaise déjà ce serait bien gros), mais DEUX. CENT. SOIXANTE. DIX. GIGAS…

J’arrive pas à piger, mais je m’en remettrai :-) .

Je vois une explication éventuelle, c’est qu’ils gardent toutes les révisions hebdomadaires depuis des années, ça doit bien faire enfler. 

 

Une hypothèse pour expliquer cette taille est que les binaires sont également dans le dépôt. Ca semble illogique à première vue, mais si le dépôt contient vraiment tout les parties (os+lib+apps), imaginer le temps qu’il faut pour compiler tout ce qui est nécessaire pour juste commencer à valider une modification dans un environnement à jour. Donc peut-être que chaque team commit aussi les binaires dans le but de permettre aux autres développeurs de disposer de version à jour rapidement. Cela pourrait aussi permettre de tester plusieurs versions de certains binaires pour des tests de régression de l’ensemble. Mais tout cela n’est qu’une hypothèse sans aucun fondement…

OlivierJ Abonné

Le 09/02/2017 à 00h06

ErGo_404 a écrit :

Rien n’indique qu’il n’y a qu’un seul OS. D’ailleurs on peut lire sur d’autres sites qu’ils ont tous les Windows dans le même repo.

Et il y a un paquet de versions Windows…

Je ne vois pas bien la raison d’utiliser le même dépôt pour plusieurs versions, surtout vu la volumétrie en question.

Après, je suppose que XP n’est plus dedans, il resterait Vista (?), 7, 8 (si cette version existe vu la 8.1), 8.1, 10. Et comme la 10 est en “rolling release”, il n’y a pas de 11 ou 12 en parallèle.

Enfin, je m’en fiche un peu, c’est leur merde.

OlivierJ Abonné

Le 09/02/2017 à 00h06

Peut-être, mais même avec les binaires, OMG !

ErGo_404

Le 06/02/2017 à 20h40

Git n’est pas toujours utilisé en système distribué. En fait les règles dépendent un peu de la méthode de travail de l’entreprise, mais ce n’est pas rare du tout d’avoir des développeurs qui poussent vers un repo central unique, et aucun lien entre les différents développeurs.

Arimane

Le 06/02/2017 à 20h40

bagofgnutea a écrit :

De l’opensource ? part Microsoft ?!

License MIT

je me disais aussi.

Microsoft a toujours aimer linux mais pas GNU.

Commentaire sans intérêt :

“C’est une licence de logiciel libre[1] et open source[2], non copyleft, permettant donc d’inclure des modifications sous d’autres licences, y compris non libres.

La licence donne à toute personne recevant le logiciel le droit illimité de l’utiliser, le copier, le modifier, le fusionner, le publier, le distribuer, le vendre et de changer sa licence. La seule obligation est de mettre le nom des auteurs avec la notice de copyright.

Elle est très proche de la nouvelle licence BSD, seule la dernière clause diffère. Elle est compatible avec la GNU General Public License.”

C’est une licence encore plus permissive et compatible GNU GPL. Merci, aurevoir.

ErGo_404

Le 06/02/2017 à 20h43

En même temps on n’utilise pas une gentoo pour autre chose qu’un besoin très spécifique, celui de n’avoir que ce qu’on veut sur sa machine ;-)

Même pour des barbus, gentoo c’est un peu hardcore quand même.

DorianM

Le 06/02/2017 à 21h19

ErGo_404 a écrit :

Git n’est pas toujours utilisé en système distribué. En fait les règles dépendent un peu de la méthode de travail de l’entreprise, mais ce n’est pas rare du tout d’avoir des développeurs qui poussent vers un repo central unique, et aucun lien entre les différents développeurs.

Yep, je confirme, c’est le cas où je bosse, on clone tous les dépôts en local mais on push uniquement vers un serveur central. Le principe est le même que sur un SVN mais on préfère Git, notamment pour sa gestion des branches.

127.0.0.1

Le 06/02/2017 à 23h18

Certes, les ratios sont pas les mêmes. " />

Hors-sujet, mais ceux que ca intéresse peuvent voir le code source (40 ko, hors directx) de la demo “Elevated” (4k)

127.0.0.1

Le 06/02/2017 à 23h34

Ah, et j’oubliais le PDF qui explique la mise au point du truc.

/fin du hors-sujet/

jcdr

Le 06/02/2017 à 23h48

C’est même bien plus qu’une simple conviction: c’est confirmé par un développeur de MIcrosoft:

&nbsphttp://www.zdnet.com/article/anonymous-msft-developer-admits-linux-is-faster-tha…

Cela dit, dans le cas de Git c’est pas vraiment difficile à constater tant l’architecture de Git est optimisée pour Linux.

La page suivante &nbsphttps://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-sto…  est très intéressante et montre bien que GVFS est une couche qui permet d’éviter au maximum l’utilisation du système de fichier local qui dans leur cas est NTFS. Et ce au prix de devoir être connecté au serveur à chaque fois d’un nouveau fichier est lu.

jcdr

Le 07/02/2017 à 01h25

psn00ps a écrit :

Au premier git diff ou git status, il va devoir lire les 270Go, non ?" />

Non, et c’est justement ce qui fait que Git est si rapide. Lors d’un git diff ou status, seul le métadonnées des dossiers sont consultées dans un premier temps. Pratiquement, un strace git status montre que pour chaque dossier il n’y a que 4 petits appels système:

 

openat(AT_FDCWD, “drivers/rtc/”, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 10

getdents(10, / 10 entries /, 32768)    = 1392

getdents(10, / 0 entries /, 32768)    = 0

close(10)                               = 0

 Cela fait très peu de donnée mais suffit pour déterminer si chacun des fichiers du dossier ont été modifiés ou pas. Normalement toutes les données requises pour cela sont dans les caches du noyau en mémoire vive, donc le média de stockage n’est quasiment pas accédé. Du coup c’est très très rapide.

C’est seulement si un fichier a été modifié qu’il est lu et comparé, mais cela concerne généralement très peu de fichiers pour chaque commit.

neojack

Le 07/02/2017 à 02h17

apres toutes ces années il n’y a eu aucun dev indelicat pour faire un git clone sur son ordi, un coup de winrar, et passer le tout sur piratebay ?

Bejarid

Le 07/02/2017 à 05h00

jcdr a écrit :

C’est même bien plus qu’une simple conviction: c’est confirmé par un développeur de MIcrosoft:

 http://www.zdnet.com/article/anonymous-msft-developer-admits-linux-is-faster-tha…

Cela dit, dans le cas de Git c’est pas vraiment difficile à constater tant l’architecture de Git est optimisée pour Linux.

La page suivante  https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-sto…  est très intéressante et montre bien que GVFS est une couche qui permet d’éviter au maximum l’utilisation du système de fichier local qui dans leur cas est NTFS. Et ce au prix de devoir être connecté au serveur à chaque fois d’un nouveau fichier est lu.

Le premier lien est un vulgaire troll (qui fait honte non seulement au “site” qui l’a publié avec un bon gros titre pute-a-clic des familles, mais aussi à quiconque le répand).

Le deuxième lien dit exactement le contraire : GVFS est une surcouche à NTFS qui permet à GIT de ne plus fonctionner uniquement en mode local, mais aussi en mode distant : the system seamlessly fetches the content from the cloud (and then stores it locally so future accesses to that data are all local). Ce “local”, c’est bien sur NTFS, GVFS ne faisant que la partie “non-fetched” (regarde le projet github pour plus de détails).

TL;DR : t’es un troll qu’a des problèmes de compréhension.

YamaLandia

Le 07/02/2017 à 08h33

sdesbure a écrit :

pour ton 1), le kernel Linux gère lui aussi beaucoup de drivers (et peut être même plus que windows…). Pourtant il ne fait “que” 800Mo (soit ~300 fois moins), sachant qu’il a démarré il y a 25 ans donc bon…

Le “truc” c’est que windows c’est le kernel Linux + la glibc + x.org + qt + KDE (ou un autre ;)) + konqueror + kalc + …

 Et ce qu’il disent c’est que tout est super imbriqué.

Après peut être qu’il vont au fur et à mesure désimbriquer certaines parties (je pense que la calculatrice doit pouvoir être un projet à part entière facilement ;) ) et ils auront moins de super repos mais pour le moment c’est trop compliqué.

J’y vois en tout cas un avantage de l’open source qui a permis d’avoir des repos à taille humaine (enfin, KDE c’est quand même 21M de lignes de code mais explosé en 300 projets)

Mauvais exemple, la calculatrice est déjà séparée de Windows " /> Elle fonctionne comme une application du store maintenant.

psn00ps

Le 07/02/2017 à 09h14

bla bla bla vous êtes des trolls,… c’est Honteux !

#fakenews

OlivierJ Abonné

Le 07/02/2017 à 10h24

bagofgnutea a écrit :

Définie moi “besoin spécifique” ^^

j’utilise gentoo en dehors de trisquel donc “besoin spécifique” pour moi c’est “si j’utilise pas il a rien a faire ici”

Sinon j’ai bien compris ton message ;)

Tu avais indiqué un lien vers des explications pour recompiler son noyau, je n’ai rien contre l’information au contraire, ça a peut-être servi à certains qui sont tombés sur ton commentaire. Je disais juste que c’est rarement la peine de s’embêter à compiler, même si le fait de pouvoir recompiler les sources de son système est quelque chose de génial quand on y pense, et qu’avec Gentoo on peut maîtriser (avec du temps) de façon un peu fine son système.

ErGo_404 a écrit :

En même temps on n’utilise pas une gentoo pour autre chose qu’un besoin très spécifique, celui de n’avoir que ce qu’on veut sur sa machine ;-)

Même pour des barbus, gentoo c’est un peu hardcore quand même.

J’ai été tenté à une époque en tant que geek curieux et programmeur, mais je n’ai jamais été bien loin au final, les distributions classiques me convenant bien.

jinge a écrit :

Pour les 270Go tu ne peux pas comparer le système d’exploitation au noyau (Le framework .Net c’est beaucoup moins par exemple). Windows il y a aussi windows server, probablement office?, visual studio et toutes les suites logicielles que MS a développé

Ben non, c’est bien des sources de Windows 10 dont il s’agit, c’est ça qui est dément.

OlivierJ Abonné

Le 07/02/2017 à 10h36

neojack a écrit :

apres toutes ces années il n’y a eu aucun dev indelicat pour faire un git clone sur son ordi, un coup de winrar, et passer le tout sur piratebay ?

Tu as dû rater un truc : la taille du dépôt et du RAR résultant. J’ai même été le premier à m’en effarer.

jcdr a écrit :

C’est même bien plus qu’une simple conviction: c’est confirmé par un développeur de MIcrosoft:

http://www.zdnet.com/article/anonymous-msft-developer-admits-linux-is-faster-tha…

Cela dit, dans le cas de Git c’est pas vraiment difficile à constater tant l’architecture de Git est optimisée pour Linux.

Bejarid a écrit :

Le premier lien est un vulgaire troll (qui fait honte non seulement au “site” qui l’a publié avec un bon gros titre pute-a-clic des familles, mais aussi à quiconque le répand).

Il est exact que Git tient compte de Linux depuis le début, ça n’a rien d’insultant de constater qu’il est plus lent sous Windows. A l’inverse, à une époque (1ere moitié des années 2000), Apache avait été mesuré plus lent que IIS pour les fichiers statiques, ça a été pris en compte et amélioré, avec l’appel système sendfile().

L’article de ZDNet prend quand même quelques pincettes en parlant de “développeur supposé de chez MS” ; par ailleurs, il n’y a pas besoin d’être un ancien développeur de chez MS pour mesurer l’efficacité des OS ou des filesystems. MS est une énorme société et il n’est pas étonnant que la gestion du vieux code y soit problématique, et qu’il soit sous-optimal. Il est vrai que NTFS est plutôt solide, cependant sous Linux j’ai toujours constaté qu’il prend beaucoup de CPU, même avec des transferts limités à de l’USB 2 (~ 35 Mo/s).

jcdr

Le 07/02/2017 à 10h49

Bejarid a écrit :

Le premier lien est un vulgaire troll (qui fait honte non seulement au “site” qui l’a publié avec un bon gros titre pute-a-clic des familles, mais aussi à quiconque le répand).

Le deuxième lien dit exactement le contraire : GVFS est une surcouche à NTFS qui permet à GIT de ne plus fonctionner uniquement en mode local, mais aussi en mode distant : the system seamlessly fetches the content from the cloud (and then stores it locally so future accesses to that data are all local). Ce “local”, c’est bien sur NTFS, GVFS ne faisant que la partie “non-fetched” (regarde le projet github pour plus de détails).

TL;DR : t’es un troll qu’a des problèmes de compréhension.

Il y a un autre lien dans la page du premier qui explique le problème avec plus de détails.

 Cela dit, il suffit de tester un peu Git sous Linux ou sous Windows pour constater qu’il y a une différence. J’en ai fait l’expérience avec un client avec qui on a développé un système embarqué Linux qui utilise aussi un DSP dont le compilateur ne fonctionne que sous Windows. Comme le but était sur le long terme de transférer les fonctions du DSP sur le processeur ARM sous Linux, on a décidé de mettre toutes les sources dans le même dépôt. Du coup, en fonction de la partie à compiler, mon portable exécutait soit Linux, soit Windows (wine et la virtualisation n’était pas utilisable pour d’autres raisons). C’était donc la même machine avec le même dépôt, soit sous Linux avec ext4, soit sous Windows 7 et NTFS. La différence était très facile à observer. Ca a du reste achevé de convaincre le client d’utiliser Linux un peu partout dans son entreprise.

Un dernier point facile à vérifier en cherchant sur le net: Linux depuis sa toute première version publiée est optimisé pour une gestion de système de fichier multithread. Ca toujours été une priorité pour Linus Torvalds au point d’être un des points du célèbre conflit avec Andrew Tanenbaum. Finalement il ne faut pas oublier que c’est justement Linus Torvald qui a fait l’architecture de Linux et de Git, donc ce n’est pas surprenant que les deux sont très optimisés pour fonctionner ensemble avec le maximum de performances. Windows et NTFS n’était pas conçus avec la même architecture ne peut que difficilement produire la même performance avec Git.

L’article explique très bien que GVFS agit comme un filtre dont le but est de minimiser la quantité de donnée à stocker dans NTFS, C’est donc bien NTFS qui est le problème. CQFD.

Fumble Abonné

Le 07/02/2017 à 15h23

il y a aussi le fait que les demomakers utilisent des outils pour compresser l’exécutable obtenu en bout de chaine. Avec UPX ou .kkrunchy par exemple pour ne citer que ceux qui me viennent spontanément à l’esprit.

Bejarid

Le 06/02/2017 à 16h01

OlivierJ a écrit :

" />

C’est des mecs de chez MS qui ont codé ça ?

Qu’est-ce qui te fait penser que Angular vient de MS ?

OlivierJ Abonné

Le 06/02/2017 à 16h02

Bejarid a écrit :

A parce que Windows contient pas de drivers peut-être ? :p

Et Windows, ce n’est qu’un kernel peut-être, y a pas 25 milles outils embarqué en plus dans le bouzin ? :p

Des drivers de base j’imagine, mais c’est connu que quand on installe un Windows quelque part, il faut aller chercher les drivers ensuite pour une partie du matériel, qui est souvent livré avec le CD d’installation d’ailleurs.

25 000 outils, rien que ça ? y a quoi d’important dedans ? Il ne faut pas oublier que de base, il y a peu d’outils dans Windows.

Bejarid a écrit :

Y a pas mal de soft de MS qui sont gigantesques en termes de lignes de codes, et ce n’est pas étonnant, leurs soft ont tellement de fonctionnalités dans tous les sens…

J’imagine, vu la taille à installer derrière… Mais on parlait de l’OS, pas d’un MS-Office ou autre Visual Truc.

Enfin, si la description de la taille des sources de Windows te paraît normale, OK.

Bejarid a écrit :

Qu’est-ce qui te fait penser que Angular vient de MS ?

Ce n’était pas vraiment une question, si tu as suivi :-) .

bobbob601

Le 06/02/2017 à 16h07

des drivers préintégrés, il y en a des milliers ET… c’est moins que par le passé. Depuis que Microsoft a forcé le format WHQL, les constructeurs ont factorisés leurs drivers et Microsoft propose meme des drivers dit génériques, que les constructeurs doivent gérer (standard d’un claiser USB par exemple).

Sous Windows XP, le premier à avoir des drivers intégrés, c’etait déjà 15% du poids du CD juste pour les drivers d’imprimante, alors que les gens ont au mieux UNE imprimante.

maintenant oui tu as un CD avec le pilote dessus mais dans 90% des cas, ton périphérique marche en grande partie sans ce CD, et grâce au pilote générique.

c’était la minute culture car on dévie du sujet " />

Bejarid

Le 06/02/2017 à 16h10

127.0.0.1 a écrit :

Bref, une très bonne idée de Ms de proposer ce GVFS, mais rien d’exceptionnel question ingénierie.

Le “we invented a bit of tech” est un peu “too mutch”, de mon point de vue.

Je pense que le “a bit of tech” veut justement dire pas révolutionnaire. Juste des petits trucs. A bit. Petit. You know…

Mais ils ont bien fait quelques avancées, non seulement coté système de fichiers virtuels, mais aussi coté GIT :

As we progressed, as you’d imagine, we learned a lot.  Among them, we learned the Git server has to be smart.  It has to pack the Git files in an optimal fashion so that it doesn’t have to send more to the client than absolutely necessary – think of it as optimizing locality of reference.  So we made lots of enhancements to the Team Services/TFS Git server.  We also discovered that Git has lots of scenarios where it touches stuff it really doesn’t need to.  This never really mattered before because it was all local and used for modestly sized repos so it was fast – but when touching it means downloading it from the server or scanning 6,000,000 files, uh oh.  So we’ve been investing heavily in is performance optimizations to Git.  Many of them also benefit “normal” repos to some degree but they are critical for mega repos.  We’ve been submitting many of these improvements to the Git OSS project and have enjoyed a good working relationship with them.

white_tentacle Abonné

Le 06/02/2017 à 16h12

Enfin, si la description de la taille des sources de Windows te paraît normale, OK.

Je pense que ça inclut l’historique.

Sinon, à 30 caractères / ligne de code en moyenne (ce qui est une moyenne haute), on serait à 10 milliards de lignes de code pour arriver à cette taille là.

À ma connaissance, on est au moins un ordre de grandeur en dessous, plutôt 2 (~100 millions de ligne de code).

Par rapport au rapport source / taille du binaire, ça dépend beaucoup. Perso, sur mes projets, j’ai pas mal de cas où le binaire est plus gros que le source (avec les templates C++, c’est assez fréquent). Et je parle bien de l’exécutable compilé en release.

sylvere

Le 06/02/2017 à 16h15

rien n’empêche de l’utiliser localement sur sa machine: on pourrait ainsi avoir sur sa machine de dev un seul clone git complet de 270GB sur lequel tourne un serveur GVFS que l’on synchronise quand on veut à partir des remotes que l’on veut.

Du coup on garde le distribué tout en ayant les gains énormes de vitesse sur les clones, les checkouts et les status

jcdr

Le 06/02/2017 à 16h20

Une partie du problème de Git sous Windows vient justement de WIndows qui est beaucoup plus lent que Linux pour les opérations les plus courantes de Git. Ce n’est pas un hasard: quand il y développé Git, LinusTorvalds cherchait le maximum de performances et comme il est plus que bien placé pour savoir ce qui va vite sous Linux, il y basé l’architecture de Git spécifiquement pour Linux (au point d’en abuser avec quelques trucs comme l’attribut de montage ‘noatime’). Donc forcément ça ne va pas aussi vit sur Windows qui déjà à la base a un problème de performance avec les grosses opérations sur les systèmes de fichier.

Le code d’un noyau Linux prend actuellement environ 800Mo avec environ 60’000 fichiers et même sur mon vieux AMD A10-7850K il ne faut que 0.5 secondes pour faire un git status ou un git diff sur tout le code. A priori même avec un code délirant de 270Go ça ne devrait pas prendre tellement plus de 3 minutes. Délirant car ça semble difficile de croire qu’il ne soit pas possible d’organiser autant de données dans de multiples sous-projets, une possibilité qui est maintenant très bien supportée par Git. Il doit y avoir un sérieux problème historique d’organisation des données…

Finalement il faut rappeler ici que Git a pour but principale de pouvoir fonctionner de façon totalement décentralisée, ce qui implique une copie complète locale du dépôt. Il y a quelques possibilités pour augmenter les performances en limitant le transfert initial, mais cela peut demander des transferts ultérieurs. La proposition de Microsoft semble miser beaucoup sur cette technique mais la conséquence est qu’il faut certainement un lien constant avec un serveur central.

127.0.0.1

Le 06/02/2017 à 16h23

Bejarid a écrit :

Je pense que le “a bit of tech” veut justement dire pas révolutionnaire. Juste des petits trucs. A bit. Petit. You know…

Mais ils ont bien fait quelques avancées, non seulement coté système de fichiers virtuels, mais aussi coté GIT

C’est une question de point de vue:

Est-ce que modifier GIT pour gérer des mega-repository est une amélioration ?

Ou est-ce un aveu d’échec a rendre la codebase modulaire ?

De manière similaire:

Est-ce que le “Hybrid Boot” qui permet d’accélérer le chargement de windows est une amélioration ?

Ou est-ce un aveu d’échec à booter rapidement sans préparer à l’avance une image mémoire ?

Comme déjà dit, GVFS (et d’une manière générale la partition de MS à GIT) est une bonne chose. J’aurais simplement préféré un GVFS qui fonctionne avec la version actuelle du Git OSS project, plutot qu’un GVFS qui nécessite la version MS de GIT.

Bejarid

Le 06/02/2017 à 16h24

OlivierJ a écrit :

Des drivers de base j’imagine, mais c’est connu que quand on installe un Windows quelque part, il faut aller chercher les drivers ensuite pour une partie du matériel, qui est souvent livré avec le CD d’installation d’ailleurs.

25 000 outils, rien que ça ? y a quoi d’important dedans ? Il ne faut pas oublier que de base, il y a peu d’outils dans Windows.

J’imagine, vu la taille à installer derrière… Mais on parlait de l’OS, pas d’un MS-Office ou autre Visual Truc.

Enfin, si la description de la taille des sources de Windows te paraît normale, OK.

Ce n’était pas vraiment une question, si tu as suivi :-) .

Non, Windows n’embarque pas que des drivers “de base”. Il fait pour pouvoir s’installer sur énormément de machine (toutes version confondu, desktop, server, embedded, iot, hololens, phone, whatever). Le repo embarque la partie bas niveau permettant de gérer tout ce cas, non seulement aujourdh’ui, mais également il y a 20 ans.

les outils que tu vois, ce n’est évidemment qu’une fractionde ce qui est installé. Fait une recherche de les .exe sur un windows fraichement installé tu va rigolé. Et même ça ne n’est pas tout ce qui est installé. Ajoute tous les outils spécifiques à certains version de windows, et oui, l’ordre de grandeur est de 5 (le 25 est bien sur très approximatif, même quelqu’un chez MS aurait bien du mal à te donner un chiffre exacte d’ailleurs " />).

Je donnais un peu de contexte. Même des outils moins vaste, et avec moins de variante que Windows sont aussi très gros, de par le fonctionnement de MS qui embarque chaque demande d’évolution spécifique dans ses produits. C’est le problème de progiciel très répandu… Ce n’est pas un cas courant ceci-dit, je comprend donc que ça étonne, mais il y a bien une explication, ce n’est pas dû à de soi-disant mauvaise pratique de codage…

Étrange comme non question. Sur qu’elle laisse entendre que c’est un produit MS. Problème de rhétorique ?

Cashiderme

Le 06/02/2017 à 16h34

Ça veut dire qu’il faut avoir obligatoirement accès au repo pour bosser, ou il y a un mode “offline” quand même ?

Bejarid

Le 06/02/2017 à 16h34

127.0.0.1 a écrit :

C’est une question de point de vue:

Est-ce que modifier GIT pour gérer des mega-repository est une amélioration ?

Ou est-ce un aveu d’échec a rendre la codebase modulaire ?

De manière similaire:

Est-ce que le “Hybrid Boot” qui permet d’accélérer le chargement de windows est une amélioration ?

Ou est-ce un aveu d’échec à booter rapidement sans préparer à l’avance une image mémoire ?

Comme déjà dit, GVFS (et d’une manière générale la partition de MS à GIT) est une bonne chose. J’aurais simplement préféré un GVFS qui fonctionne avec la version actuelle du Git OSS project, plutot qu’un GVFS qui nécessite la version MS de GIT.

Op op op, tu tires bien trop vite des conclusions !

Il n’y a pas de version MS de GIT, ce qu’ils ont fait c’est des optimisations au projet OSS de GIT, et elles ont été acceptés. Et elles ne profitent pas qu’aux méga-projets, elles profitent aussi aux gros gestionnaires de GIT (type GitHub). C’est écrit dans ma citation, tu en veux une traduction en français ?

Ensuite, tes procès d’aveux d’échecs sont pitoyables. Oui, ça prendre du temps de booter un OS polyvalent et tout terrain, donc faut trouver des astuces qui accélérer ça, pleins. Oui c’est extrêmement couteux que d’essayer de rendre une codebase aussi grosse et vielle que Windows modulaire (ils ont essayé de le faire pendant 6 mois, puis on fait machine arrière, le fil qu’ils avaient tiré était beaucoup trop long…).

Ils racontent aussi que Bing (un de leur jeunes produits) est parti sur une codebase modulaire, et qu’ils essayent de la remerger car en faite y a trop de problème de versionning. Aucune solution n’est parfaite.

 

Tout ça c’est assez évident quand on a travaillé dans des gros projets, ça n’a rien de spécifique à MS.

Bejarid

Le 06/02/2017 à 16h37

Cashiderme a écrit :

Ça veut dire qu’il faut avoir obligatoirement accès au repo pour bosser, ou il y a un mode “offline” quand même ? 

Apparemment y a une option pour forcer une synchro globale, donc faire du offline puisque tout est alors dans le cache locale.

psn00ps

Le 06/02/2017 à 16h37

Au premier git diff ou git status, il va devoir lire les 270Go, non ?" />

OlivierJ Abonné

Le 06/02/2017 à 16h41

jcdr a écrit :

Une partie du problème de Git sous Windows vient justement de WIndows qui est beaucoup plus lent que Linux pour les opérations les plus courantes de Git. […] l’architecture de Git spécifiquement pour Linux (au point d’en abuser avec quelques trucs comme l’attribut de montage ‘noatime’). Donc forcément ça ne va pas aussi vit sur Windows qui déjà à la base a un problème de performance avec les grosses opérations sur les systèmes de fichier.

Je ne pense pas que ce soit le “noatime” le plus significatif dans l’histoire (d’ailleurs depuis longtemps les montages par défaut sont en “relatime” qui revient au même pour la lecture) ; c’est plutôt la gestion des liens durs (hard links, par opposition aux soft links) il me semble.

jcdr a écrit :

Le code d’un noyau Linux prend actuellement environ 800Mo avec environ 60’000 fichiers et même sur mon vieux AMD A10-7850K il ne faut que 0.5 secondes pour faire un git status ou un git diff sur tout le code. A priori même avec un code délirant de 270Go ça ne devrait pas prendre tellement plus de 3 minutes. Délirant car ça semble difficile de croire qu’il ne soit pas possible d’organiser autant de données dans de multiples sous-projets, une possibilité qui est maintenant très bien supportée par Git. Il doit y avoir un sérieux problème historique d’organisation des données..

" />

Bejarid

Le 06/02/2017 à 16h42

jcdr a écrit :

Une partie du problème de Git sous Windows vient justement de WIndows qui est beaucoup plus lent que Linux pour les opérations les plus courantes de Git.

 

Le pire, c’est que t’es surement convaincu de ce que tu dis. C’est fou.

bagofgnutea

Le 06/02/2017 à 16h45

De l’opensource ? part Microsoft ?!

License MIT

je me disais aussi.

Microsoft a toujours aimer linux mais pas GNU.