Gnu bazaar est un logiciel de gestion de versions libre, appartenant au projet Gnu et maintenu par la société Canonical (l'éditeur de la distribution Ubuntu). La version 2.6.0 de ce logiciel, distribué sous licence Gnu GPL v2, a été publiée le 4 août dernier. Parmi les nouveautés, on notera notamment :
- l'option --store de la commande bzr garde dorénavant les modifications n'ayant pas fait l'objet d'un commit dans la branche, et les restaure lors d'un retour en arrière dans la branche ;
- la nouvelle option –context de la commande bzr diff permet de configurer le nombre de lignes à afficher autour de chaque changement ;
- les plugins grep et ping sont dorénavant fournis avec bzr.
Aller plus loin
- bazaar (158 clics)
# #troll
Posté par haleth . Évalué à -8.
Un projet qui porte bien son nom ..
# Lauchpad
Posté par Dazul . Évalué à -2.
Directement après l'installation de Bazaar sur une machine Debian, j'ai trouvé que Bazaar était beaucoup trop lié à Launchpad.
[^] # Re: Lauchpad
Posté par barmic . Évalué à 5.
Pourquoi ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Lauchpad
Posté par ariasuni . Évalué à 4.
Tu peux détailler?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Lauchpad
Posté par Dazul . Évalué à -1.
Simplement parce que je n'ai eu à spécifier que la repository sans avoir besoins de dire sur quel serveur.
[^] # Re: Lauchpad
Posté par mxt . Évalué à 2.
Je parie que le repository en question était de la forme lp:xxxx. Le préfixe "lp:" est une espèce d'alias qui indique justement le serveur: bazaar.launchpad.net.
Il est possible d'utiliser bzr sans le préfixe "lp:" et donc se passer du serveur launchpad.
[^] # Re: Lauchpad
Posté par Zenitram (site web personnel) . Évalué à -3.
Zut alors, ne pas laisser l'utilisateur avec un truc inutilisable après l'installation, c'est trop pour certains…
# Quels avantages face à la cathédrale ?
Posté par Sam E. (site web personnel) . Évalué à 4.
En me baladant sur le site officiel je suis tombé sur cette page qui présente pourquoi on devrait passer à Bazaar.
La liste des points présentés est la suivante (ils sont plus détaillés sur le site) :
En parcourant la page, je me suis dit qu'il n'y avait pas vraiment d'avantages par rapport à git, mais il y a en fait deux points qui me paraissent intéressants.
Bazaar apparemment supporte les répertoires d'autres gestionnaire de version
Le logiciel peut être étendu avec des extensions
Qu'est-ce que vous en pensez ?
Ce serait intéressant d'avoir des retours d'utilisation.
[^] # Re: Quels avantages face à la cathédrale ?
Posté par ckyl . Évalué à 10.
Tu as raison. Bazaar est une bonne idée qui a mal tournée et qui devrait être parti à la poubelle depuis longtemps à cause de git/hg.
Ce n'est pas qu'il peut c'est qu'il doit.
Ce qui implique d'avoir 5-10 extensions, personne n'a les mêmes, la moitiée ne sont pas maintenue ou mal gaulées. Un vrai plaisir !
J'ai du me farcir bazaar pendant ces 9 derniers mois. Franchement bazaar est une sale blague, c'est:
Bref de nos jours je vois pas pourquoi on s'emmerderait avec. L'argument de la possibilité de faire du centralisé est moisi c'est le pire des deux mondes. Bazaar est mourrant et à fait pleins d'erreurs qui ont d'ailleurs été documenté ici et là par des auteurs. En tant qu'utilisateur tu te dis que ce que tu observes en utilisant est confirmé par les devs… Passe ton chemin.
[^] # Re: Quels avantages face à la cathédrale ?
Posté par Sam E. (site web personnel) . Évalué à 2.
Okay, au moins c'est clair exposé comme ça \o/
[^] # Re: Je vois des gens qui sont morrts
Posté par madhatter (site web personnel) . Évalué à -1.
Bazaar est tellement lent, plein d'erreurs et sa politique anti-rebase tellement drôle, que tu mets deux "r" à mourir, partout ! :D
There is no spoon...
[^] # Merge ou rebase ?
Posté par woprandi . Évalué à 2.
D'ailleurs vous êtes plus merge à tout va ou rebase ? Ou un mix des deux lorsque vous gerêr votre code ?
[^] # Re: Merge ou rebase ?
Posté par ckyl . Évalué à 4.
Mix des deux.
Le rebase est un outil très puissant pour les branches non publiées. Il te permet de garder un historique propre quand tu mets à jour tes branches locales. Avec bazaar, sans le plugin rebase, tu ne comprends plus rien à ton historique après 10 merges alors que tu as juste mis à jour ta branche contre sa branche d'origine.
Après tu as le rebase interactif, qui n'existe pas dans bazaar. Il te permet entre autre d'avoir des "checkpoint" faciles au cours du dev, d'éviter de tout mélanger dans des gros commits dégueux, ou de sortir des patch sets propres quand tu bosses upstream avec soumissions de patch ou de branches. Tu as des outils de patch managements au dessus de DCVS mais pour la plupart des usages ce que fourni git est suffisant. Bazaar a réussi à me resigner à pousser des commits dégueux par ce que ca n'a pas de sens de perdre 1h pour des choses simples :(
Après pour le merge il faut faire attention car git et bazaar ont deux approches différentes. Bazaar ne fait jamais de "fast-forward" c'est à dire qu'il créé toujours un commit de merge, git lui laisse le choix et par défaut linéarise l'historique quand c'est possible. Ces deux opérations n'ont pas la même sémantique et il est de bon ton de bien spécifier le
no-ffà git selon l'opération que l'on fait.D'une manière générale A successful Git branching model est assez intéressant comme point réflexion initial. Après pour ce qui est local, chacun fait un peu comme il veut. Je suis certain que beaucoup de choses ont été écrites à ce sujet.
[^] # Re: Merge ou rebase ?
Posté par fredoche . Évalué à 2.
Les deux sont complémentaires pour 1-partager un historique de dev sous la forme que tu veux 2- intégrer le taf de tes collaborateurs sans risque:
Perso, souvent , avant de merge, dans un premier temps, je rebase ma branche avec --onto pour la faire partir exactement de là où c'est pertinent, puis je la merge --no-ff pour faire clairement apparaitre le fait que j'ai travaillé dans une branche , et pouvoir facilement dé-merger tout un dev en cas de problème (un seul commit à revert).
En l’occurrence, un dev qui vise la version 3 d'un logiciel peut être effectué dans une branche d'abord tirée de la version 1 , puis rebasé sur la version 2 pour intégrer les bugfix de cette branche, puis rebasé sur la version 3, idem on re-adapte la branche au socle, puis mergé sur la version 3.
Perso, ça me permet de démarrer un dev indépendamment de sa date, forme, de livraison.
Pour ce qui est de l'impossibilité/desactivation de rebase de branche distante, je dirais qu'on peut toujours rebaser, puis change le nom de la branche, etc. Pas de problème concernant le risque de perdre l'historique donc.
[^] # Re: Je vois des gens qui sont morrts
Posté par ckyl . Évalué à 3.
Si il n'y a que ca qui te choque dans mes commentaires. Un correcteur grammatical serait morrt depuis longtemps ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.