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é.
ETA pour la feature dans mercurial: quelques semaines. En effet Matt Mackall (le créateur du projet) est payé par Sun pour l'implementer et il a une deadline.
Après, c'est clair qu'ils se sont concentrés sur les fonctionalités et non sur les perfs.
Pour moi ce qui ressortait de la discussion au sprint de Londres, c'est qu'ils ont fait des choix qui limiteront forcement la performance (notamment le choix d'un identifiant unique pour les fichiers) et que pour arriver au niveau de hg/git, bzr devra passer par (encore) un changement de format du repository.
tout est encore en python contrairement à Mercurial qui a déjà les parties critiques en performances optimisées en C, ...).
Une seule chose a été optimisé (et ca a été fait dès le début du projet) c'est les méthodes pour patcher/differ qui sont forcement critique. Ca semble la première chose à optimiser et je me demande pourquoi bzr ne le fait pas (le reste n'est pas encore optimiser pour que ce soit critique ?)
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).
Et si bzr était aussi intrinsequement plus lent ?
[^] # Re: Performances...
Posté par ribwund . En réponse à la dépêche bzr 0.11 vient de sortir. Évalué à 4.
ETA pour la feature dans mercurial: quelques semaines. En effet Matt Mackall (le créateur du projet) est payé par Sun pour l'implementer et il a une deadline.
Après, c'est clair qu'ils se sont concentrés sur les fonctionalités et non sur les perfs.
Pour moi ce qui ressortait de la discussion au sprint de Londres, c'est qu'ils ont fait des choix qui limiteront forcement la performance (notamment le choix d'un identifiant unique pour les fichiers) et que pour arriver au niveau de hg/git, bzr devra passer par (encore) un changement de format du repository.
tout est encore en python contrairement à Mercurial qui a déjà les parties critiques en performances optimisées en C, ...).
Une seule chose a été optimisé (et ca a été fait dès le début du projet) c'est les méthodes pour patcher/differ qui sont forcement critique. Ca semble la première chose à optimiser et je me demande pourquoi bzr ne le fait pas (le reste n'est pas encore optimiser pour que ce soit critique ?)
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).
Et si bzr était aussi intrinsequement plus lent ?