Les principales nouveautés de cette version sont l'apparition d'un serveur dédié (pour le moment uniquement à travers ssh) ainsi que des améliorations de performances. bzr est un logiciel de gestion de versions écrit exclusivement en python. Son but est de rendre l'utilisation de la gestion de version décentralisée simple tout en permettant un grand nombre de fonctionnalités.
Ce projet fut initié par Canonical. bzr est capable de s'auto-gérer depuis mars 2005. Basée initialement sur les idées de GNU Arch, ses développeurs tentent de réunir tout les points forts des différents logiciels de ce type dans un même programme.
À ses débuts, le principal reproche fait à bzr était ses faibles performances. Depuis la version 0.7, les performances ont été très fortement améliorées, pour le rendre aujourd'hui utilisable sur de gros projets.
bzr est le logiciel de gestion de versions décentralisé libre regroupant le plus de fonctionnalités. Notons notamment le support complet officiel sous Windows, le support d'un système de greffons ainsi qu'une vraie gestion des renommages de fichiers.
Aller plus loin
- Site officiel de Bazaar (français) (3 clics)
- Site officiel de Bazaar (2 clics)
- Performances de bazaar (1 clic)
- Comparaison des logiciels de gestion de version (2 clics)
- DLFP : Des nouvelles des gestionnaires de versions GNU Arch et Bazaar (1 clic)
# Performances...
Posté par ribwund . Évalué à 10.
cache chaud
nombres de fichiers: ~20k (kernel linux)
taille: 280M
temps pour ajouter + commiter les fichiers:
bzr: 5min 1s
hg: 1min 56s
temps pour faire un status:
bzr: 6.6s
hg: 1.3s
taille du repo:
bzr: 232M
hg: 126M
bzr est le logiciel de gestion de versions décentralisé libre regroupant le plus de fonctionnalités.
Ca me semble quand même un peu exagéré, et pas forcement respectueux des devs des autres systèmes (darcs, monotone, git, mercurial, ...)
[^] # Re: Performances...
Posté par Philippe F (site web personnel) . Évalué à 3.
En dehors de ses performances, est-ce que bazaar sait faire des choses mieux que les autres. Quid de hg, j'avais jamais entendu parle. C'est stable ?
[^] # Re: Performances...
Posté par TeXitoi (site web personnel) . Évalué à 2.
hg = mercurial. Mercurial est inspiré de git. Son but premier est la rapidité. Il est stable et utilisé par quelques gros projets (OpenSolaris notamment).
[^] # Re: Performances...
Posté par ribwund . Évalué à 4.
Je sais pas d'ou vient cette idée mais git et mercurial ont été commencé le même jour d'ailleurs mercurial a été utilisable avant git (cf les archives du kernel). Si un SCM a vaguement inspiré git et mercurial c'est monotone (la façon dont sont utilisés les hash).
[^] # Re: Performances...
Posté par Matthieu Moy (site web personnel) . É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).
[^] # Re: Performances...
Posté par ribwund . É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 ?
[^] # Re: Performances...
Posté par gS . Évalué à 3.
Pour le moment notre code ne contient que environ 80K lignes de code, mais ca grossit relativement vite ( la précédente version de notre soft toujours géré sous CVS a à peu pres 380K lignes ). Nous prévoyons que la nouvelle version sera plus conséquente que la précédente et pour le moment, nous n'envisageons pas de passer à autre chose que bazaar-ng.
Les perfs au commit/update ne sont pas vraiment un problème (pour nous, en tout cas), je ne pense pas que ca soit la meilleur façon de juger ce type d'outil. (a moins de faire un unpdate toute les 20 minutes :)
La fonctionnalité que j'appécie le plus sont les bound branches. Elles permettent d'émuler un fonctionnement centralisé ou chaque commit se fait simultanément sur le repository central et localement, on utilise que les commande commit/update. C'est tres pratique. Quand on le souhaite,on peu passer en mode décentralisé et se synchroniser avec la source que l'on veut ou bosser uniquement en local puis repasser en bound sur le serveur central avec une commande tres simple.
Les explications de James Blackwell sur le sujet (un des gars qui fait du support et aide les débutants) m'on vraiment bien aidé.
a++
Guillaume.
[^] # Re: Performances...
Posté par golum . Évalué à 5.
Un ptit lien pour que tout le monde en profite ?
[^] # Re: Performances...
Posté par gS . Évalué à 5.
a++
[^] # Re: Performances...
Posté par vrm (site web personnel) . Évalué à 1.
[^] # Re: Performances...
Posté par gS . Évalué à 2.
a++
[^] # Re: Performances...
Posté par golum . Évalué à 5.
Dans l'approche centralisée avec bzr tu peux travailler en concurrence d'accès sur une branche hebergée sur un repository partagé.
A chaque fois que tu commites tu le fais à la fois dans ton archive locale et dans l'archive centrale.
Il en résulte une certaine complexité dans l'utilisation de l'outil comme tu pourras t'en apercevoir dans le lien suivant mais la possibilité existe
http://bazaar-vcs.org/SharedRepositoryTutorial
Hg ne se concentre que sur le modèle distribué. (Un repository par développeur et chaque utilisateur récupère les modifs des autres et les intègre dans sa branche.)
Il a effectivement été retenu par l'équipe d'OpenSolaris qui fournit un dossier de choix assez approfondi
http://www.opensolaris.org/os/community/tools/scm/;jsessioni(...)
[^] # Re: Performances...
Posté par wilk . Évalué à 3.
[^] # Re: Performances...
Posté par TeXitoi (site web personnel) . Évalué à 1.
Ca me semble quand même un peu exagéré, et pas forcement respectueux des devs des autres systèmes (darcs, monotone, git, mercurial, ...)
non, pas forcément. Chacuns ont leurs avantages et leurs inconvénients. Vu que bzr essaie de prendre les bonnes idées des voisins, il a beaucoup de fonctionnalités. Darcs est surtout facile à utiliser, mais il n'est pas utilisable sur des projets de taille moyenne à grande. git ne fonctionne pas sous windows (cygwin, ca compte pas, hein ;-)). Mercurial a des fonctionnalités très proche de bzr, mais ses inconvénients face à bzr sont l'absence de renomage de fichier (copy+delete sous hg), le fait de ne pouvoir forker une nouvelle branche en local sans recopier tout l'historique uniquement s'il y a support des liens dur, ainsi qu'un support de windows pas aussi bon que bzr. (monotone, je connais pas)
Il n'en reste que hg est très rapide (bien que certaines parties soient programmé en C contrairement à bzr), et qu'a mon avis, le futur va se jouer entre bzr et hg.
[^] # choix
Posté par or zax . Évalué à 7.
bzr est chapoté par Canonical, et quand on voit les promesses en l'air fait par rapport à bazaar première génération, que les utilisateurs se sont fait planter, avec un système plus maintenu, une politique de migration qui n'a pas plus de consistence que le vide inter-sidéral : utiliser une technologie géré par Canonical est un trop gros risque pour une utilisation professionnelle.
Moi c'est Mercurial, j'ai la tranquilité d'esprit maintenant.
[^] # Re: choix
Posté par ribwund . Évalué à 7.
D'ailleurs pour contribuer à bzr il faut assigner son copyright à Canonical, et je sais pas pourquoi mais je pense que Canonical c'est pas la FSF, ils font pas ça pour passer le logiciel en GPLv3 par la suite... (surtout sachant que Launchpad est propriétaire et qu'ils cherchent à integrer Launchpad+bzr au maximum)
[^] # Re: choix
Posté par Olivier Grisel (site web personnel) . Évalué à -1.
De plus la migration de repositories arch/baz -> bzr est toujours supportée AFAIK.
[^] # Re: choix
Posté par or zax . Évalué à 5.
Pour information, une migration ne consiste pas juste en un utilitaire de conversion, c'est aussi un support. Il y a qu'a voir à quel point les développeurs normalement assigné à bazaar sont présent sur la mailing-list.
Tout une partie de ceux qui utilisait baz ont du choisir grosso-modo entre bzr et revenir à tla, car du jour au lendemain, canonical décide que
gérer correctement baz ce n'était plus assez fun.
Désolais mais canonical derrière des outils aussi important c'est dangereux, le fait qu'une société a de l'argent ne garantie pas de la pérennité, mais assujeti le projet au bon vouloir de la société en question.
Actuellement tous les copyrights sont au nom de canonical en plus d'après ce que je viens de lire, ce qui veut dire que Canonical peut rendre propriétaire du jour au lendemain bzr.
bzr c'est une bombe à retardement, amis kamikaze, amusez vous bien avec bzr, vous rigolerez moins après.
[^] # Re: choix
Posté par Olivier Grisel (site web personnel) . Évalué à 2.
http://bazaar-vcs.org/HistoryOfBazaar :
Par ailleurs, un logiciel GPL ne peut pas "être rendu propriétaire", la version distribuée sous license GPL continuera d'être libre même si canonical décidait de publier une nouvelle version sous licence proprio. Et de toute manière ca serait suicidaire de leur part de le faire : leurs utilisateurs feraient un fork ou switcheraient en masse vers une autre solution si tel était le cas.
[^] # Re: choix
Posté par or zax . Évalué à 4.
Pour ce qui est de la licence GPL, focément, mais c'est gentil de toujours dire, la communauté peut reprendre, mais au bout d'un moment elle en marre de rattraper les dégâts, en plus cela divise les utilisateurs, suffit que la version proprio rende incompatible les versions suivantes avec la précédente et c'est le bazaar sans faire de mauvais jeu de mots.
bzr dans l'état actuel des choses (cela peut évoluer en bien et je l'espère) est une prise de risque inutile au vu de l'existant, et de la main mise de canonical.
[^] # Re: choix
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
Non, non, après un an à crier haut et fort que la version 1.5 était juste retardée, mais pas abandonnée, Robert a bien annoncé qu'il abandonnait. Ils ont pas peur du ridicule ...
(pour rappel, je suis l'auteur d'une bonne partie des modifs commitées dans la branche 1.5 qui n'a jamais été releasée)
> ce qui veut dire que Canonical peut rendre propriétaire du jour au lendemain bzr.
Là, par contre, c'est faux. Le copyright assignment est là :
http://bazaar-vcs.org/CopyrightAssignment
voir le point 6. Canonical peut distribuer bzr sous une licence propriétaire, mais s'engage à le distribuer aussi sous une licence libre au sens de la FSF.
Perso, je n'ai aucune confiance en Canonical pour la maintenance à long terme, mais je crois qu'il y a suffisament de gens qui s'intéressent à bzr pour qu'un fork apparaisse si les gens de Canonical font les cons. Avec baz, ça n'était pas le cas, vu que quand ils ont abandonné leur bébé, la plupart des gens étaient déjà sous bzr, ou encore sous tla. Mais je peux me tromper.
[^] # Re: Performances...
Posté par ribwund . Évalué à 3.
cElementTree (parsing de xml en C) est quand même fortement conseillé pour bzr :)
# Monotone
Posté par Vivi (site web personnel) . Évalué à 9.
Quelqu'un a posté récemment une comparaison de VCS dans comp.lang.ada :
http://www.ada-france.org/debian/distributed-version-control(...)
http://groups.google.com/group/comp.lang.ada/msg/bf2f9970828(...)
Il a choisi monotone :
J'aime bien sa comparaison :
(bon, bien sûr tout le monde sait que le meilleur langage de l'Univers c'est OCaml, pas Ada).
[^] # Re: Monotone
Posté par golum . Évalué à 4.
Une branche n'est pas une véritable branche au sens d'une séquence linéaire de version.
Il s'agit plutôt d'une notion logique qui s'apparente à un effort de développement. Elle ressemble plutôt à un fuseau de versions avec une étiquette.
Losrqu'on travaille dans une branche monotone, on n'a pas besoin de forker une branche pour travailler dasn son coin.
On se synchronise et committe sans se poser de question. Lorsqu'on récupère les modifs des autres dans son repository, Monotone detecte les version des fichiers qui ont divergé et on peut les réconcilier.
D'autre part Monotone implémente son propre système de synchronisation (netsync) même si il peut passer à travers tout autre type de protocole. L'approche est consistante et efficace.
Enfin le developpeur principal du projet est quelqu'un d'assez ouvert. Il s'etait rapporché des devs de Codeville pour échanger sur les algorithmes de merge. Il est à l'origine de la création du wiki
http://revctrl.org/FrontPage
sur lequel des devs des VCS les plus en vues sont inscrits
[^] # Re: Monotone
Posté par golum . Évalué à 5.
Au contraire, je pense que c'est cette conception qui fait la force de svn.
Pour quelqu'un qui a pris l'habitude de faire des copies de sauvegardes de ses petits devs
en recopiant son arbo, c'est on ne peut plus naturel.
Mais surtout l'algorithme de tag/branche est en O(n) et la plupart du temps bien au dessous du cas limite.
Tous les développeurs qui ont déjà attendu 1h avant de tagger un gros projet sous Clearcase ou Perforce
peuvent témoigner.
Pour ceux qui veulent approfondir le sujet
http://subversion.tigris.org/files/documents/15/158/svn.zip
M'as l'air d'être un beau trolleur de compét le sieur.
[^] # Re: Monotone
Posté par Boa Treize (site web personnel) . Évalué à 3.
En adaptation libre :
P.S. : Git n'a pas vraiment besoin de Cogito pour être utilisable, et n'est plus vraiment « l'assembleur dont il faut combiner les instructions » d'il y a un an...
[^] # Re: Monotone
Posté par golum . Évalué à 1.
http://linuxfr.org/comments/756569.html#756569
Et alors comme Linus il l'a dit et ben c'est vrai.
Tout le monde sur DLFP va gober la divine parole du grand gourou.
Pour être un peu plus constructif, tu aurais pu nous fournir le reste de la conversation pour savoir ce qu'il reproche exactement la numérotation des révisions:
Le fait d'historiser les versions au lieu des diff comme Gnu Arch ?
Mieux tu pourrais nous fournir une petite analyse et poster un journal sur le sujet en t'en tenant à ses arguments
[^] # Re: Monotone
Posté par Boa Treize (site web personnel) . Évalué à 6.
Je n'ai en aucun cas prétendu que Linus avait raison, et d'ailleurs, comme je l'avais dit quand j'avais traduit son troll lors de la sortie de la dernière version de Linux, sur ce point précis il avait tort. (Mais son opinion sur Subversion demeure.)
Sur ce point précis :
Un utilisateur est venu demander si on pouvait modifier Git pour disposer d'un numéro de révision qui s'incrémente monotoniquement, pour pouvoir faire comme sur les projets qui utilisent Subversion, et dire simplement aux utilisateurs "utilise la révision 393" ou "c'est corrigé dans la révision 532".
Linus est parti de travers la dessus (ce qui lui arrive rarement), et a donc pondu ces phrases mémorables sur la qualité de CVS et Subversion (bon ça, ça lui arrive plus souvent), et notamment une grande tirade sur la numérotation des branches dans CVS (1.1.1.5, ce genre de trucs effectivement bien horrible mais qui n'avait rien à voir avec ce que l'utilisateur demandait).
Après un petit recadrage d'autres contributeurs de Git, les arguments suivants ont été retenus :
- C'est faisable dans Git, mais ça fait une métadonnée à mémoriser en plus, et un changement qui impacte pas mal de commandes de Git
- Communiquer une version abrégée de l'identifiant du commit concerné fonctionne aussi bien ("utilise le commit 5ef24" ou "c'est corrigé dans le commit 63b43")
- Ce genre de communication est plus liée à un projet organisé autour d'un référentiel centralisé et qui utilise peu de branches ; dans les projets plus distribués et/ou qui utilisent plus de branches, on a plutôt tendance à dire "utilise la branche new_features" ou "c'est corrigé dans la branche bugfixes".
Au final, vu tout ça, la conclusion a été "si quelqu'un le veut vraiment, qu'il propose un patch".
Sur Subversion et CVS :
C'est tout l'argument centralisé contre distribué, politique des projets, etc. qu'il faudrait reprendre. Ce que je ne vais pas faire là maintenant.
[^] # Re: Monotone
Posté par golum . Évalué à 3.
Tu fais partie de mes contradicteurs "préférés" sur les VCS et ton post paraissait ambigu. Sans plus de précision, j'ai extrapolé...a tort, n'ayant pas relu tout le thread sur la dernière sortie de Linux.
Comme on dit par chez nous, "je suis parti comme un pet sur une toile cirée"
A propos de Subversion et CVS je ne te demandais pas un argumentaire complet, on a déjà pas mal echangé sur le jet. Je souhaitais juste que tu précises les griefs argumentés du sieur Linus. Tu l'a précisé il était hors-sujet.
Le débat est clos et je serais mal placé pour lui en tenir rigueur.
[^] # Re: Monotone
Posté par Vivi (site web personnel) . Évalué à 1.
Euh j'ai du mal à voir comment on peut avoir des numéros de révision incrémenentaux dans un système complètement distribué: il faut quelque part une autorité centrale qui vérifie qu'il n'y a pas de collision.
Bon évidemment dans le cas de Subversion y'a pas de problèmes vu que c'est centralisé.
[^] # Re: Monotone
Posté par Olivier Grisel (site web personnel) . Évalué à 1.
[^] # Re: Monotone
Posté par Boa Treize (site web personnel) . Évalué à 2.
[^] # Re: Monotone
Posté par golum . Évalué à 1.
Calculer tous les hash sur les fichiers de la configuration (aborescence) et les mettre dans un fichier manifeste.
Et le hash de ce manifeste identifie la configuration
[^] # Re: Monotone
Posté par Boa Treize (site web personnel) . Évalué à 2.
Ce que la personne voulait, c'était un numéro séquentiel.
[^] # Re: Monotone
Posté par golum . Évalué à 2.
Un même patch peut être appliqué à plusieurs arborescences et ne suffirait donc pas.
Je ne connais pas git et je pensais qu'il avait la même architecture que Arch (historique basé sur les patchs/changeset et non sur les versions)
[^] # Re: Monotone
Posté par Boa Treize (site web personnel) . Évalué à 3.
Rapidement :
Le coeur de Git, c'est de stocker des objets, et de les identifier par leurs somme de contrôle (SHA1 actuellement). Git ne gère que quatre types d'objets :
- le blob, qui est un gros tas d'octets dans lequel Git ne met pas son nez ; concrètement, les différentes versions des fichiers mis en conf sont stockées sous forme de blob
- l'arbre, qui contient des pointeurs vers des blobs et possiblement vers d'autres arbres ; c'est ce qui permet de mémoriser l'arborescence des fichiers
- le commit, qui contient un pointeur vers un arbre (la racine des fichiers dont on souhaite mémoriser l'état) et vers un ou plusieurs autres commits (les ancêtres de ce commit, ce qui permet de constituer l'historique du développement, et de gérer les branches)
- le tag, objet plus anodin qui pointe vers n'importe quel objet précédent, et porte un nom (genre v2.6.16.7) et optionnellement une signature.
Donc, comme Mercurial (et Monotone ?), Git stocke l'état des fichiers aux divers moments du développement, et génère le diff entre deux états à la volée. Contrairement à Arch ou Darcs, par exemple, qui stockent les diff et génèrent l'état à la demande.
Le reste de Git, c'est de la fioriture. ;-)
- Programmes de bas niveau pour gérer ces objets
- Programmes pour compacter tous ces objets en un pack qui consomme beaucoup moins d'espace disque et gérer ce genre de pack
- Programmes pour envoyer et recevoir ces objets par divers protocoles
- Programmes pour générer et digérer des patches de toutes sortes
- Programmes pour interroger les données dans tous les sens (diff, grep très puissant, logs plus ou moins verbeux, etc.)
- Programmes pour chercher à quel endroit on a introduit un bug
- Programmes pour importer les données d'autres gestionnaires de conf
- Programmes pour encore plein de trucs divers et variés plus ou moins annexes
- Et bien sûr programmes de plus haut niveau pour pas se prendre la tête dans la vie de tous les jours ;-)
Le tout étant à peu près correctement documenté. Git a fait beaucoup de progrès depuis ses débuts. :-)
Doc pour débuter :
Everyday Git
http://www.kernel.org/pub/software/scm/git/docs/everyday.htm(...)
Vue d'ensemble
http://www.kernel.org/pub/software/scm/git/docs/
[^] # Re: Monotone
Posté par Christophe Fergeau . Évalué à 2.
En plus, vu comment c'est développé le noyau, je pense pas que linus soit intéressé par un scm centralisé, donc il a pas dû passer beaucoup de temps à regarder svn ou cvs.
[^] # Re: Monotone
Posté par Boa Treize (site web personnel) . Évalué à 2.
D'ailleurs, après avoir utilisé un truc proprio qui lui convenait bien, il a créé son propre truc qui lui convient bien. ;-)
# Repository sur Launchpad
Posté par Mildred (site web personnel) . Évalué à 3.
Ca peut être fait avec n'importe quel hébergement HTTP, c'est vrai, mais là ou c'est plus intéressant, c'est que tu peux dans launchpad créer des groupes et travailler à plusieurs sur la même branche.
Et là, je n'ai pas encore trouvé d'hébergement gratuit permettant d'avoir plusieurs login/mot de passe pour le même espace de stokage.
https://launchpad.net/bazaar
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.