« Mieux », c'est toujours une question de point de vue.
Le lien sur la comparaison dans la dépêche donne une idée. Pour moi, les killer-features de bzr, c'est la possibilité d'héberger des projets sur à peu près n'importe quel serveur web (il suffit d'avoir ftp/sftp et http, rien d'autre à installer sur le serveur), le fait qu'on peut choisir entre « 1 branche = une copie de travail » à la darcs/hg/git et « 1 branche peut avoir plusieurs checkouts » (comme avec le bon vieux CVS/svn/...).
La gestion des renomages est vraiment bonne. À l'ajout d'un fichier ou d'un répertoire, un identifiant unique est créé (comme dans GNU Arch), et le nom du fichier est une information comme une autre après. En comparaison, Mercurial ne sait pas maintenir une branche avec un fichier renommé, et ne gère pas, par exemple, un ajout de fichier dans un répertoire renommé.
Mais on peut sûrement trouver des cas où c'est Mercurial ou git qui aurait l'avantage. Darcs est excellent pour la gestion des patch individuelle (cherrypicking) par exemple.
Après, c'est clair qu'ils se sont concentrés sur les fonctionalités et non sur les perfs. Aujourd'hui, c'est encore lent en comparaison avec hg ou git, mais c'est déjà rapide comme l'éclair comparé à ce qu'on avait il y a même pas 6 mois. Il y a encore du boulot d'optimisation sur la todolist (le « smart server » n'est qu'une ébauche pas du tout optimisée, tout est encore en python contrairement à Mercurial qui a déjà les parties critiques en performances optimisées en C, ...). La question est plus de savoir où s'arrêteront les gains de performance, il y a de bonnes chances que ça se joue à quelques dizaines de pourcent près à terme (Darcs restera sans doute à la traine, puisqu'il est basé sur des concepts qui le rendent intrinsèquement plus lent, et déjà bien optimisé aujourd'hui).
[^] # Re: Performances...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche bzr 0.11 vient de sortir. Évalué à 5.
Le lien sur la comparaison dans la dépêche donne une idée. Pour moi, les killer-features de bzr, c'est la possibilité d'héberger des projets sur à peu près n'importe quel serveur web (il suffit d'avoir ftp/sftp et http, rien d'autre à installer sur le serveur), le fait qu'on peut choisir entre « 1 branche = une copie de travail » à la darcs/hg/git et « 1 branche peut avoir plusieurs checkouts » (comme avec le bon vieux CVS/svn/...).
La gestion des renomages est vraiment bonne. À l'ajout d'un fichier ou d'un répertoire, un identifiant unique est créé (comme dans GNU Arch), et le nom du fichier est une information comme une autre après. En comparaison, Mercurial ne sait pas maintenir une branche avec un fichier renommé, et ne gère pas, par exemple, un ajout de fichier dans un répertoire renommé.
Mais on peut sûrement trouver des cas où c'est Mercurial ou git qui aurait l'avantage. Darcs est excellent pour la gestion des patch individuelle (cherrypicking) par exemple.
Après, c'est clair qu'ils se sont concentrés sur les fonctionalités et non sur les perfs. Aujourd'hui, c'est encore lent en comparaison avec hg ou git, mais c'est déjà rapide comme l'éclair comparé à ce qu'on avait il y a même pas 6 mois. Il y a encore du boulot d'optimisation sur la todolist (le « smart server » n'est qu'une ébauche pas du tout optimisée, tout est encore en python contrairement à Mercurial qui a déjà les parties critiques en performances optimisées en C, ...). La question est plus de savoir où s'arrêteront les gains de performance, il y a de bonnes chances que ça se joue à quelques dizaines de pourcent près à terme (Darcs restera sans doute à la traine, puisqu'il est basé sur des concepts qui le rendent intrinsèquement plus lent, et déjà bien optimisé aujourd'hui).