Ceci dit, aucun des deux ne sont vraiment « terminés », l'équipe de bzr ne s'est pas tellement concentrée sur les perfs pour l'instant, mais c'est plus une question d'implémentation qu'une question de modèle, donc, on peut s'attendre à des progrès importants dans les prochaines versions.
Par exemple, bzr n'a pas de serveur dédié. Gros avantage : on peut héberger une branch ou un repository bzr sur n'importe quel serveur, du moment qu'il y a du (s)ftp pour uploader et du HTTP statique pour downloader. L'inconvénient, c'est que du coup, le protocole n'est pas bien pipeliné, on n'exploite pas bien la bande passante. Le serveur dédié est sur la todolist de bzr.
Autre différence : bzr est 100% python. L'intérêt, c'est que ça s'installe plus facilement. Sur un bzr fraichement téléchargé, ./bzr va marcher direct, rien à compiler. Ça simplifie l'installation sur les machines n'ayant pas de compilo C (souvent le cas sous Windows). Bien sûr, on perds encore en perfs, mais évidemment, il y a des gens qui se penchent sur la question, et maintenant que les fonctionalités de bzr sont à peu près stabilisées, certains développeurs font du profiling et ont commencé à voir ce que ça donne de surcharger certaines méthodes python par une réimplémentation en C, et les gains en perfs sont immédiats.
Bref, aujourd'hui, hg est largement devant bzr niveau perfs, mais je ne vois pas de raisons pour que les deux ne deviennent pas à peu près équivalents d'ici quelques mois.
[^] # Re: Mercurial
Posté par Matthieu Moy (site web personnel) . En réponse au journal Quel gestionnaire de révisions pour un "débutant". Évalué à 2.
Ceci dit, aucun des deux ne sont vraiment « terminés », l'équipe de bzr ne s'est pas tellement concentrée sur les perfs pour l'instant, mais c'est plus une question d'implémentation qu'une question de modèle, donc, on peut s'attendre à des progrès importants dans les prochaines versions.
Par exemple, bzr n'a pas de serveur dédié. Gros avantage : on peut héberger une branch ou un repository bzr sur n'importe quel serveur, du moment qu'il y a du (s)ftp pour uploader et du HTTP statique pour downloader. L'inconvénient, c'est que du coup, le protocole n'est pas bien pipeliné, on n'exploite pas bien la bande passante. Le serveur dédié est sur la todolist de bzr.
Autre différence : bzr est 100% python. L'intérêt, c'est que ça s'installe plus facilement. Sur un bzr fraichement téléchargé, ./bzr va marcher direct, rien à compiler. Ça simplifie l'installation sur les machines n'ayant pas de compilo C (souvent le cas sous Windows). Bien sûr, on perds encore en perfs, mais évidemment, il y a des gens qui se penchent sur la question, et maintenant que les fonctionalités de bzr sont à peu près stabilisées, certains développeurs font du profiling et ont commencé à voir ce que ça donne de surcharger certaines méthodes python par une réimplémentation en C, et les gains en perfs sont immédiats.
Bref, aujourd'hui, hg est largement devant bzr niveau perfs, mais je ne vois pas de raisons pour que les deux ne deviennent pas à peu près équivalents d'ici quelques mois.