bzr 0.11 vient de sortir

Posté par (page perso) . Modéré par Jaimé Ragnagna.
Tags :
0
2
oct.
2006
Python
bzr viens de sortir en version 0.11. bzr, aussi connu sous le nom bazaar-NG, est un logiciel de gestion de version sponsorisé par Canonical.

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

    Posté par . Évalué à  10 .

    Ca faisait longtemps que j'avais pas retesté bzr alors vu qu'ils font beaucoup de buzz par rapport aux performances j'ai fait un petit test (hg est également écrit en python):

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

      Ca, c'est du cassage en regle !

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

        Voir le lien "Comparaison des logiciels de gestion de version" au dessus (hébergé par bazaar, avec un lien vers le comparatif de wikipedia).

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

          Mercurial est inspiré de git.

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

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

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

        Concernant bazaar-ng, noun l'utilisons dans ma boite depuis 1 an. Les perfs s'améliorent de version en version et les plugins s'étoffent.
        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 . Évalué à  5 .

        bzr tente de supporter pleinement le modèlé distribué et le modèle centralisé.

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

        Vu l'activité impressionante du développement actuel de bazaar, il est vraiment trop tôt pour mesurer quoi que ce soit ! Ceci dit ça a toujours été très stable depuis le début.
    • [^] # Re: Performances...

      Posté par (page perso) . Évalué à  1 .

      hg reste plus performant, c'est sur. D'ailleur, c'est le but premier de hg, d'être performant. Il n'empêche que les performances ont été grandement amélioré dans bzr.

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

        Le choix va être vite fait pour tous ceux qui ont comme soucis la pérénité de leurs projets.

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

          bzr est chapoté par Canonical
          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 (page perso) . Évalué à  -1 .

          Je trouve justement que le support de canonical perenise ce logiciel, notamment son intégration avec le portail launchpad.net qui fournit un moyen très simple de démarrer un projet open source sans avoir à configurer de serveur.

          De plus la migration de repositories arch/baz -> bzr est toujours supportée AFAIK.
          • [^] # Re: choix

            Posté par . Évalué à  5 .

            Et bien regarde à quel point bazaar est pérenne, la sortie de baz 1.5 est toujours prévu pour 2005 ?

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

              bzr est le successeur officiel de baz donc c'est normal qu'il faille upgrader son repository (ou rester avec la dernière version de baz si elle convient).

              http://bazaar-vcs.org/HistoryOfBazaar :

              Canonical Ltd had a need for a decentralized version control system. At the time, the closest fit to their need was Gnu Arch, however there was some difficulty in adapting it to fit their exact needs.

              So Canonical created a Bazaar project. Initially it was thought that the fork of Gnu Arch now known as Baz-1.x would become the official Bazaar project. After some limitations in the Gnu Arch model had been uncovered, a prototype initially called Bazaar-NG was created. Eventually, this prototype became quite robust and easier to use.

              Historically the project has had several names, but it is now just simply known as Bazaar.


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

                Bon je me répète, une migration ne consiste pas juste à convertir un dépôt, le problème n'est donc pas la mise à jours, mais le suivie et le support, l'adaptation des procédures de développements etc ... chose que canonical avait promis de faire mais n'a pas fait.



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

              > Et bien regarde à quel point bazaar est pérenne, la sortie de baz 1.5 est toujours prévu pour 2005 ?

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

        bien que certaines parties soient programmé en C contrairement à bzr
        cElementTree (parsing de xml en C) est quand même fortement conseillé pour bzr :)
  • # Monotone

    Posté par (page perso) . Évalué à  9 .

    C'est dommage qu'on ne parle pas plus de monotone je trouve. C'est vraiment bien conçu et tout à fait utilisable depuis un bout de temps. La version 0.30 est sortie il y a 2 semaines : http://venge.net/monotone/ .

    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 :
    I believe that Monotone is the Ada of version control systems, so it is only appropriate that I use it for my Ada work. Monotone is safe, correct and powerful _by design_. It uses cryptographic keys to authenticate changes. It is written by elite programmers who, despite using C++, have the "Ada attitude": no pointers, one assert() every 9 lines of code, massive use of generics (templates), and not a single critical bug in 3 years.

    J'aime bien sa comparaison :
    I like to think that...
    CVS is the "C" of version control systems,
    Subversion is the "C++" designed to replace the "C",
    GIT is the "assembly language" who needs cogito to be useable,
    Bazaar-NG is the "perl", grossly inefficient and completely baroque,
    Mercurial is the "Eiffel" i.e the second best,
    Monotone is the "Ada", i.e. the best, even if not perfect

    (bon, bien sûr tout le monde sait que le meilleur langage de l'Univers c'est OCaml, pas Ada).
    • [^] # Re: Monotone

      Posté par . Évalué à  4 .

      Oui c'est vrai que l'approche de Monotone est vraiment élegante.

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


      (I particularly dislike Subversion and its distributed derivative,
      SVK. I do not recommend them because their working model is
      inherently broken, IMHO. A branch is NOT a directory, and a tag is
      NEITHER a branch NOR a directory.

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

        Pfff, rien du tout, le vrai trolleur c'est Linus Torvalds ! :-)

        I really don't think you can do it sanely.

        The thing is, the reason subversion can do it is simply that SVN is terminally broken.

        Really. SVN is crap. It may be prettier crap than CVS, but it's literaly no different from putting confectioners sugar on top of a cowpatty. It's not really "fixing" anything. And the revision numbering is actually very much part of the problem.


        En adaptation libre :

        Je ne pense vraiment pas que ça puisse être fait proprement.

        Le truc, la raison pour laquelle subversion peut faire ça c'est simplement que SVN est une foirade irrémédiable.

        Vraiment. SVN c'est de la merde. C'est peut-être une merde plus avenante que CVS, mais c'est littéralement la même chose que de mettre du sucre en poudre sur de la bouse de vache. Subversion ne "corrige" en fait rien du tout. Et la numérotation des révisions est un symptome typique des problèmes de subversion.


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

          Oui tu nous l'a déjà faite ici.
          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 (page perso) . Évalué à  6 .

            Le but est (était ?) de comparer les gros trolls velus que certaines grandes gueules bien connues peuvent pondre parfois.

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

              Merci pour ces précisions. Je reconnais que mon post etait un peu acide et je te prie de m'en excuser.

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

              sur ce point précis il avait tort
              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 (page perso) . Évalué à  1 .

                Dans ce cas, on utilise des numéros de révisions propres à chaque branche (ce qui est le cas de BZR en tout cas).
              • [^] # Re: Monotone

                Posté par (page perso) . Évalué à  2 .

                Une telle numérotation aurait bien sûr été limité au niveau du repository. Mais la plupart des projets ayant un seul repository officiel, la fonctionnalité aurait quand même pu être utile. Ceci dit, c'était effectivement un autre argument en défaveur de cette demande.
                • [^] # Re: Monotone

                  Posté par . Évalué à  1 .

                  Tu as aussi la solution de Monotone:
                  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 (page perso) . Évalué à  2 .

                    C'est ce que je mentionnais quand je parlais "d'identifiant du commit" plus haut. Sur ce point Git fonctionne comme Monotone je crois. (Mais je connais très peu Monotone.)

                    Ce que la personne voulait, c'était un numéro séquentiel.
                    • [^] # Re: Monotone

                      Posté par . Évalué à  2 .

                      Désolé j'avais compris que c'était un id de patch.
                      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 (page perso) . Évalué à  3 .

                        Si on ne connaît pas l'architecture de Git, c'est sûr que ce n'est pas facile à comprendre. J'aurais dû utiliser une formulation plus claire.

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

            A mes yeux, c'est pas trop dur de comprendre pourquoi linus aime pas svn. La facon dont il bosse pour le noyau, c'est de merger en permanence des patches en provenance d'une multitude de branches. Et bon, que ça soit svn ou cvs, le merge répété d'une branche dans un repo, c'est déjà pas ça du tout...
            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 (page perso) . Évalué à  2 .

              Ca va plus loin que ça : il connaît et a toujours détesté CVS, il a regardé et n'aime pas beaucoup plus Subversion.

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

    Je viens de découvrir quelque chose de très intéressant, il suffit d'avoir un compte sur Launchpad pour pouvoir créer des branches sue le serveur launchpad, et les partager avec le reste du monde.

    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.