Sortie de Gnu Bazaar 2.6.0

Posté par . Édité par Xavier Teyssier. Modéré par patrick_g. Licence CC by-sa
Tags : aucun
18
9
août
2013
Gestion de versions

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.
  • # #troll

    Posté par . Évalué à -8.

    Un projet qui porte bien son nom ..

  • # Lauchpad

    Posté par . É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 . É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 (page perso) . Évalué à 4.

      Tu peux détailler?

      Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Lauchpad

        Posté par . É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 . É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 (page perso) . É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 (page perso) . É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) :

    The top ten reasons for switching to Bazaar are:

    • Version control for everyone
    • Work offline
    • Any workflow
    • Cross platform support
    • Rename tracking and smart merging
    • High storage efficiency and speed
    • Any workspace model
    • Plays well with others
    • Launchpad
    • Plugins and bzrlib

    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

    Bazaar transparently supports foreign branches for Subversion, Git and Mercurial repositories. This means you can use normal Bazaar clients and commands on these - special commands are generally not required!

    Le logiciel peut être étendu avec des extensions

    Bazaar has over 100 plugins that extend its core capability. […] Some hackers like writing shell scripts using Git’s low level “plumbing” commands. We believe an open, supported, cross-platform API is a better way of extending and integrating with a VCS tool. See our integration guide to get started with bzrlib.

    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 . Évalué à 10.

      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.

      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.

      Le logiciel peut être étendu avec des extensions

      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 !

      Ce serait intéressant d'avoir des retours d'utilisation.

      J'ai du me farcir bazaar pendant ces 9 derniers mois. Franchement bazaar est une sale blague, c'est:

      • lent à mourrir
      • commandes et fonctionalités de bases moisies (pas de pager par défaut, options de 3km pour faire des choses simple, la detection du déplacement de fichier se vautre une fois sur une).
      • Ne tire pas du tout parti du fait que c'est un DCVS et que tu peux faire des choses sur tes branches locales que tu ne dois faire sur les publiques. Pas de rebase interactif, l'édition d'un commit non poussé est un enfer etc.
      • Ecosystème de merde. Aucun plugin d'IDE n'a été mis à jour dans les 2 dernières années
      • Tonnes de plugin plus ou moins bien gaulé. Il faut même un plugin pour avoir un workspace colocated…
      • La politique anti-rebase est à mourrir de rire "Faut pas péter l'historique" par contre ils te conseillent de sortir un diff de ta branche locale puis de faire un gros patch sur une nouvelle branche, ou tu perds… tout ton historique !
      • La version Windows à l'air assez funky (pas testé)

      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 (page perso) . Évalué à 2.

        Okay, au moins c'est clair exposé comme ça \o/

      • [^] # Re: Je vois des gens qui sont morrts

        Posté par (page perso) . É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 . É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 . É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 . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.