L'article explique que les problèmes de performance sont lié à deux choses:
- La quantité des changesets (C'est moins gros que plusieurs millions mais plein quand même)
- La quantité de fichiers versionnés
Chacune de ses dimensions va ralentir un aspect de l'outil. <hg|git> status ne va pas être affecté par le nombre de changesets mais par le nombre de fichiers. À l'inverse <git|hg> pull ne va pas vraiment être affecté par le nombre de fichier total mais par le nombre de changesets/changement à synchroniser.
Chacune des deux extensions présentées améliorent fortement une dimension dans ce sens. hgwatchman accélère la supervision des fichiers de Facebook. remotefilellog améliore le transfert des changesets créés toute les jours.
Un certain nombre d'autre modifications ont également été faite upstream. Par exemple depuis 4 versions hg update (équivalent de git checkout) est parallélisé, le calcul du contenu et l'écriture sur disque de plusieurs fichiers sont réalisés en même temps. Cela peut donner des améliorations de performance assez drastique quand on utilise des machines à plusieurs dizaines de cœurs pour des mises à jours de plusieurs milliers de fichiers.
Par ailleurs un certain nombre d'opération dans git prennent en compte l'intégralité du dépôt, comme le "packing" ou la "garbage collection". C'est opération sont donc de plus en plus lentes au fur et à mesure que le dépôt grossi. Si on prend en compte le fait que ces opérations ont des races conditions entre elle et avec un certain nombre de command de base (ceci n'est pas une blague) ça ne donne pas très envie de les voir s'étaler dans la durée. Mercurial à un format de stockage "en ajout uniquement" qui ne souffre pas de ce genre de problème tout en garantissant un stockage efficace en place et en temps de restauration.
Pour finir, je rappel que Mercurial n'a pas besoin de plusieurs clone pour utiliser plusieurs branches. Il me semble que c'est bazaar qui suit ce modèle.
[^] # Re: Investissement de facebook dans mercurial
Posté par marmoute . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 3.
L'article explique que les problèmes de performance sont lié à deux choses:
- La quantité des changesets (C'est moins gros que plusieurs millions mais plein quand même)
- La quantité de fichiers versionnés
Chacune de ses dimensions va ralentir un aspect de l'outil.
<hg|git> statusne va pas être affecté par le nombre de changesets mais par le nombre de fichiers. À l'inverse<git|hg> pullne va pas vraiment être affecté par le nombre de fichier total mais par le nombre de changesets/changement à synchroniser.Chacune des deux extensions présentées améliorent fortement une dimension dans ce sens.
hgwatchmanaccélère la supervision des fichiers de Facebook.remotefilellogaméliore le transfert des changesets créés toute les jours.Un certain nombre d'autre modifications ont également été faite upstream. Par exemple depuis 4 versions
hg update(équivalent degit checkout) est parallélisé, le calcul du contenu et l'écriture sur disque de plusieurs fichiers sont réalisés en même temps. Cela peut donner des améliorations de performance assez drastique quand on utilise des machines à plusieurs dizaines de cœurs pour des mises à jours de plusieurs milliers de fichiers.Par ailleurs un certain nombre d'opération dans git prennent en compte l'intégralité du dépôt, comme le "packing" ou la "garbage collection". C'est opération sont donc de plus en plus lentes au fur et à mesure que le dépôt grossi. Si on prend en compte le fait que ces opérations ont des races conditions entre elle et avec un certain nombre de command de base (ceci n'est pas une blague) ça ne donne pas très envie de les voir s'étaler dans la durée. Mercurial à un format de stockage "en ajout uniquement" qui ne souffre pas de ce genre de problème tout en garantissant un stockage efficace en place et en temps de restauration.
Pour finir, je rappel que Mercurial n'a pas besoin de plusieurs clone pour utiliser plusieurs branches. Il me semble que c'est bazaar qui suit ce modèle.