En gros, leur position c’est que plusieurs repo c’est une grosse erreur pour une grosse entité (C’est compliqué et ça apporte absolument rien, à part des emmerdes). Même dans une organization de taille moyenne, c’est un gros merdier à gérer (opengrok rend tout juste le,problème gerable).
Git à un parti pris très fort pour le multi repo, et n’est absolument pas adapté au mono repo.
Ca reste une philosophie qui peut se discuter, mais très honnêtement, d’un point de vue pragmatique, sorti de "ya que perforce qui soit capable de gérer un gros repo, et franchement, ça saoule de l’utiliser", ya pas vraiment d’avantages du côté du multi repo. N’importe quelle boite de taille moyenne se retrouve vite avec plus de 100 repos, et c’est un enfer à gérer à quotidien ou sur le long terme.
Ce qui n’est absolument pas discutable est que git scale tres mal sur de gros repo. La question est "combien de boîtes atteignent cette échelle", à l’heure des micro services, systèmes distribués et infrastructure as code, Ben je pense que la réponse est "beaucoup plus que ya 10 ans quand git est devenu populaire".
Alors, ouais, le kernel tourne sous git, mais ça reste un projet de relativement petite échelle, essentiellement texte, qui avance assez lentement (3 mois entre chaque release, c’est très lent dans un monde de CD avec plusieurs releases par jour à une échelle de millions, voire centaines de millions d’utilisateurs).
C’est aussi un projet très yolo avec les pratiques qualité, qui délègue les tests aux autres.
Comme rare sont ceux qui ont les reins assez solide pour implémenter leur propre dvcs dans leur coin, Ben on fait avec. Mais ya clairement matière à détrôner git.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par groumly . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 9.
Ah bah ça tombe bien, ils l’ont fait:
https://m.cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
Tu peux aussi aller demander aux studios de jeux vidéos ce qu’ils pensent de git.
En gros, leur position c’est que plusieurs repo c’est une grosse erreur pour une grosse entité (C’est compliqué et ça apporte absolument rien, à part des emmerdes). Même dans une organization de taille moyenne, c’est un gros merdier à gérer (opengrok rend tout juste le,problème gerable).
Git à un parti pris très fort pour le multi repo, et n’est absolument pas adapté au mono repo.
Ca reste une philosophie qui peut se discuter, mais très honnêtement, d’un point de vue pragmatique, sorti de "ya que perforce qui soit capable de gérer un gros repo, et franchement, ça saoule de l’utiliser", ya pas vraiment d’avantages du côté du multi repo. N’importe quelle boite de taille moyenne se retrouve vite avec plus de 100 repos, et c’est un enfer à gérer à quotidien ou sur le long terme.
Ce qui n’est absolument pas discutable est que git scale tres mal sur de gros repo. La question est "combien de boîtes atteignent cette échelle", à l’heure des micro services, systèmes distribués et infrastructure as code, Ben je pense que la réponse est "beaucoup plus que ya 10 ans quand git est devenu populaire".
Alors, ouais, le kernel tourne sous git, mais ça reste un projet de relativement petite échelle, essentiellement texte, qui avance assez lentement (3 mois entre chaque release, c’est très lent dans un monde de CD avec plusieurs releases par jour à une échelle de millions, voire centaines de millions d’utilisateurs).
C’est aussi un projet très yolo avec les pratiques qualité, qui délègue les tests aux autres.
Comme rare sont ceux qui ont les reins assez solide pour implémenter leur propre dvcs dans leur coin, Ben on fait avec. Mais ya clairement matière à détrôner git.