Je ne connais pas trop BK, à part les deux trois trucs que j'ai pu lire ça et là, et c'est très difficile de faire une bonne comparaison vu que les personnes qui pourraient le mieux la faire (devs de tla) ne sont pas éligibles pour la license gratuite de BK ... mais les points faibles de Arch, à mon avis :
* Tous les messages de log sont conservés dans l'arbre de travail, chacun dans un fichier séparé. Pour le développement de Xtla, qui est un tout petit projet par rapport à Linux, l'ensemble des fichiers de log prends 8 fois plus de place sur le disque que les sources ! Résultat, il faut de temps en temps effacer des fichiers, et on perd les traces de l'historique.
* Le mode de fonctionnement par défaut de BK, c'est que le programmeur doit dire quel fichiers il modifie (en pratique, il programme son éditeur de texte pour le faire). Résultat, la plupart des operations sur l'arbre sont en O(nombre de fichiers modifiés) et non en O(nombre total de fichiers).
* Arch utilise des expressions régulières pour classifier les fichiers. C'est très pratique, sauf que le moteur d'expression régulières n'est pas des plus efficaces, donc, il y a un assez gros problème de performances a ce niveau là.
* La réactivité de l'équipe de devs. J'ai du m'y reprendre à 3 fois pour faire accepter un patch de une ligne. Si on regarde l'historique de tla depuis la version 1.2, c'est assez drôle : Une faille de sécurité dont la correction a mis plusieurs mois à être intégrée à une release officielle, une 1.2.2rc2 qui n'est jamais devenue 1.2.2 pour cause de conflits personnels entre développeurs, le changelog entre la 1.2 et la 1.3rc2 qui se trouve du coup ridiculement petit par rapport aux mois de développement qui séparent ces deux versions. La moitié des liens du site officiel www.gnuarch.org qui pointent sur une erreur 404, ... Bref, dans l'état actuel des choses, généraliser l'utilisation de arch pour un projet de grande taille me parait bien risqué ...
[^] # Re: BK conçu pour Linus
Posté par Matthieu Moy (site web personnel) . En réponse au journal BitKeeper ou Arch. Évalué à 10.
* Tous les messages de log sont conservés dans l'arbre de travail, chacun dans un fichier séparé. Pour le développement de Xtla, qui est un tout petit projet par rapport à Linux, l'ensemble des fichiers de log prends 8 fois plus de place sur le disque que les sources ! Résultat, il faut de temps en temps effacer des fichiers, et on perd les traces de l'historique.
* Le mode de fonctionnement par défaut de BK, c'est que le programmeur doit dire quel fichiers il modifie (en pratique, il programme son éditeur de texte pour le faire). Résultat, la plupart des operations sur l'arbre sont en O(nombre de fichiers modifiés) et non en O(nombre total de fichiers).
* Arch utilise des expressions régulières pour classifier les fichiers. C'est très pratique, sauf que le moteur d'expression régulières n'est pas des plus efficaces, donc, il y a un assez gros problème de performances a ce niveau là.
* La réactivité de l'équipe de devs. J'ai du m'y reprendre à 3 fois pour faire accepter un patch de une ligne. Si on regarde l'historique de tla depuis la version 1.2, c'est assez drôle : Une faille de sécurité dont la correction a mis plusieurs mois à être intégrée à une release officielle, une 1.2.2rc2 qui n'est jamais devenue 1.2.2 pour cause de conflits personnels entre développeurs, le changelog entre la 1.2 et la 1.3rc2 qui se trouve du coup ridiculement petit par rapport aux mois de développement qui séparent ces deux versions. La moitié des liens du site officiel www.gnuarch.org qui pointent sur une erreur 404, ... Bref, dans l'état actuel des choses, généraliser l'utilisation de arch pour un projet de grande taille me parait bien risqué ...