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

C’est plutôt pointu comme système quand même, non?

C’est de la triche !

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.

Il me semblait que Google n’utilisait pas/plus Git ?

(Sinon c’est à cause de l’invérifiabilité de cette information que j’y ai mis un conditionnel).

Le repo de google n’est pas un repo git par contre c’est un svn maison (piper)

Bien vu, piper, pas git, au temps pour moi !

(dont 1000 avec conflits)

Quel enfer !

Cf les posts suivants

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.

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 ?

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.

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…

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.

J’ai pas entièrement lu l’article ACM, mais je ne comprends pas l’intérêt d’unifier tous les projets en un seul dépôt, surtout si ça pose des soucis de passage à l’échelle.

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

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.

J’étais tombé là-dessus. Pas encore eu le temps de la voir mais comme ça se rapproche du sujet de ce billet, je partage !