Licence CC BY

Et le plus gros dépôt Git du monde appartiendrait à …

Dernière mise à jour :
Auteur :
Catégorie :
Temps de lecture estimé :

3 500 000 fichiers, 300 Go, 440 branches, 4 000 utilisateurs quotidiens, 10 000 merges (dont 1000 avec conflits).

C’est les stats d’un dépôt Git qui serait le plus gros du monde, parce qu’il est issu de la fusion de plus de 40 Source Depot depuis environ 3 mois (avec bascule du gros des utilisateurs la semaine du 29 mars). Et avec quelques adaptations, les performances restent tout à fait correctes (des patchs sont à prévoir dans l’upstream).

Ce dépôt, c’est celui de Microsoft Windows. Ben oui. Plein de détails dans le lien (en anglais) :)



18 commentaires

J’ai vu ça mais j’ai pas vu de comparaison avec la taille du monorepo de Google. Parce que oui, chez Google ils n’ont qu’un seul et unique repo Git avec tout dedans (depuis beaucoup plus longtemps que MS, ça fait 18 ans que Google fait ça), et eux aussi ont leur propre outil pour gérer ça : depot_tools.

Quelqu’un a vu passé une comparaison de taille ? On aime ça les concours de qui a le plus gros dépôt.

[Edit] Ouais donc ouais, c’est Google qui gagne, tu peux changer ton billet. Ils ont 35M commits, le dépôt pèse 86TB. Environ 40k commits par jour. Leur dépôt reçoit 800’000 requêtes par seconde aux heures de pointe.

Édité par cepus

+0 -0

[Edit] Ouais donc ouais, c’est Google qui gagne, tu peux changer ton billet. Ils ont 35M commits, le dépôt pèse 86TB. Environ 40k commits par jour. Leur dépôt reçoit 800’000 requêtes par seconde aux heures de pointe.

victor

"Il faut commencer par du rêve. Et les choses deviennent réelles à un moment ou un autre." - Kenny Todd, directeur des opérations pour l’ISS.

+0 -0

[Edit] Ouais donc ouais, c’est Google qui gagne, tu peux changer ton billet. Ils ont 35M commits, le dépôt pèse 86TB. Environ 40k commits par jour. Leur dépôt reçoit 800’000 requêtes par seconde aux heures de pointe.

victor
Roipoussiere

Si tu google "google 35 million commits", t’as des dizaines d’articles qui citent un article de l’ACM : https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext . Il y a peu de sources plus fiables que les articles de l’ACM. :)

+3 -0

Merci.

Par contre je ne vois à aucun endroit dans l’article la mention d’un quelquonque système de droits sur cet outil de versionnement.

Je suppose que le stagiaire du coin (ou autre CDI fraichement employé) n’a pas accès à l’intégralité des sources de tous les projets Google, vous avez une idée de comment ça se passe ?

"Il faut commencer par du rêve. Et les choses deviennent réelles à un moment ou un autre." - Kenny Todd, directeur des opérations pour l’ISS.

+0 -0

Par contre je ne vois à aucun endroit dans l’article la mention d’un quelquonque système de droits sur cet outil de versionnement.

heu…

they are not deeply familiar with is mitigated through the code-review process and the concept of code ownership. The Google codebase is laid out in a tree structure. Each and every directory has a set of owners who control whether a change to files in their directory will be accepted. Owners are typically the developers who work on the projects in the directories in question. A change often receives a detailed code review from one developer, evaluating the quality of the change, and a commit approval from an owner, evaluating the appropriateness of the change to their area of the codebase.

+2 -0

J’avais bossé pour un fabricant de smartphone, on retrouvait exactement ce fonctionnement. Pour chaque commit apporté dans le code, il fallait plusieurs validations du code par des développeurs de mon équipe (qui donc connaissait cette "région" du code) qui donnait leur "+1" puis ensuite un "+2" d’un "responsable du domaine" qui a le dernier mot sur ce qui rentre ou pas.

Chaque commit devait respecter une nomenclature, et devait être accompagné d’un test automatique ou d’un test manuel pour être validé (ou avoir une vraiment bonne excuse pour ne pas fournir de tests !).

Inutile de dire qu’on poussait pas un commit en quelques minutes/heures…

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+1 -0

Je n’ai aucune statistique sur ma boite, mais les technologies de gestion de version sont éparses et sur divers support:

  • Très vieux projets sur des hotels (des machines dédiées) qui utilisent clearquest (et rien qu’un des plus vieux projet comptabilise 15 millions de ligne pour le cœur du produit, je n’ose pas imaginé le nombre de commits).
  • Très vieux projets sous SVN notamment.
  • Vieux projets sous un mix Clearcase / Jazz.
  • Nouveaux projets git, soit sur github pour les projets open-sources (sans compter les participations, mais ça c’est comme Microsoft ou Google), soit sur un github on premise.

Je serais vraiment curieux de savoir ce que tout cela fait au total. Après, il y a le bénéfice du temps, les premiers projets versionnés datant du début des années 70. Sans vouloir trop m’avancé, comme la boite est plus vieille, aussi large et avec deux fois plus d’employés que Google et Microsoft réunis, ça doit probablement tabler sur autant sinon plus en terme de dépôts.

Malheureusement, j’ai essayé d’accéder à des statistiques du github auto-hébergé, mais impossible d’avoir quoique ce soit. :(

Édité par KFC

« Kommunist Fried Chicken » | Macroeconomics: Three decades of intellectual regress

+0 -0

Par rapport à la code base de Google, une présentation intéressante l’an dernier à la CPPCon :

Qui explique pourquoi ils ont dû réfléchir à déployer les modules en C++ avant qu’ils soient intégrés dans la standard (puisque ça n’arrivera pas avant C++20).

First : Always RTFM - "Tout devrait être rendu aussi simple que possible, mais pas plus." A.Einstein [Tutoriel Frama-C WP]

+0 -0

Merci.

Par contre je ne vois à aucun endroit dans l’article la mention d’un quelquonque système de droits sur cet outil de versionnement.

Je suppose que le stagiaire du coin (ou autre CDI fraichement employé) n’a pas accès à l’intégralité des sources de tous les projets Google, vous avez une idée de comment ça se passe ?

Roipoussiere

Seule une très faible partie (critique) du code n’est pas accessible à tous les ingénieurs (incluant les stagiaires). C’est une des raisons pour lesquels les personnes qui trouvent des problèmes simples à résoudre sont invités à envoyer directement un correctif (qui sera quasiment toujours accepté) plutôt que d’ouvrir un bug.

Autre point qui n’a pas été mentionné dans les commentaires: sauf cas très exceptionnels, il n’y a aucune branche dans le monorepo. C’est à dire que si tu développes une feature tu es forcé de la découper en morceaux assez petits pour qu’ils soient simple à vérifier/lire. Globalement, si ton commit fait plus de 500-1000 lignes modifiés (incluant les tests) et que ce n’est pas une modification simple (e.g. suppression de code inutilisé ou refactoring), tu as peu de chances pour que la modification soit accepté tel-quelle.

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte