Bazaar

• [^]Re: Bazaar

  Posté par champi (page perso, ) le 12/09/2005 à 08:30. (lien). Évalué à 8.

  C'est le but du projet bazaar-ng : s'inspirer de tout ce qui se fait de bien pour faire le meilleur système.
  
  BZr est vraiment un super système : simple et intuitif à utiliser, plus réactif qu'un subversion (car travail en local : pas de connexion réseau pour un commit), un code très testé (tests unittaires et doctests), un système de plugins pour pouvoir personnaliser et améliorer facilement et la volonté de faire du code portable (windows est supporté) pour toucher le plus grand nombre. De plus la communauté est très active avec une boîte qui embauche des devs à plein temps pour bosser sur le projet ...
  
  En plus le code est en python, bien documenté et il est donc facile d'y contribuer ce qui rend ce projet particulièrement sain. Le jeu de tests permet d'organiserer régulièrement des refactoring de composant sans tout casser.
  
  Comme tla et bazaar ferment boutiques progressivement, leurs communautés respectives se tournent vers bazaaz-ng ce qui en fait un candidat très probable pour être l'équivalent décentralisé de subversion.

  • [^]Re: Bazaar

    Posté par Nicolas Boulay () le 12/09/2005 à 08:35. (lien). Évalué à 3.

    Question bète mais pourquoi ne pas utiliser Git comme moyen de stoquage ?

    • [^]Re: Bazaar

      Posté par Zakath (page perso, ) le 12/09/2005 à 11:05. (lien). Évalué à 2.

      Parce que git est juste un gros hack écrit en vitesse par Linus Torvalds qui n'est pas spécialement un pro de la conception de scm.

      --
      Vous devriez vraiment visiter Aperture First !

      • [^]Re: Bazaar

        Posté par Nicolas Boulay () le 12/09/2005 à 11:33. (lien). Évalué à 0.

        renseignes toi avant de dire des aneries sur ce qu'est devenu git et les outils qui reposent dessus.

        • [^]Re: Bazaar

          Posté par Zakath (page perso, ) le 12/09/2005 à 23:32. (lien). Évalué à 3.

          Je suis renseigné. C'est un truc lourd qui a été écrit très rapidement pour combler un besoin ponctuel sans réel design derrière.
          Et toutes les modifications et adjonctions qu'on lui fait maintenant sont de plus en plus difficiles parce qu'elles n'ont pas été prévues dès le départ.
          Il n'y aurait pas sieur Torvalds qui pèse de tout son poids (fort subséquent par ailleurs), personne ne l'utiliserait.
          
          Franchement, arrêtez d'utiliser git et passez à des vrais scm conçus par des gens qui savent ce qu'ils font, comme mercurial ou monotone.

          --
          Vous devriez vraiment visiter Aperture First !

          • [^]Re: Bazaar

            Posté par Nicolas Boulay () le 13/09/2005 à 07:51. (lien). Évalué à 1.

            Je ne sais plus lequel des 2 mais un gars de la lkml voulait l'utiliser mais pour introduire l'historique du noyau, il aurait fallut une bonne centaine d'année de calcul...

            • [^]Re: Bazaar

              Posté par or zax () le 13/09/2005 à 10:12. (lien). Évalué à 1.

              Dans mon cas j'ai vu un rapport sur un test grandeur nature, il était question d'heures et pas de centaines d'années.
              
              J'avais aussi fait des tests mais sur les opérations de commits sur l'arborescence du noyau, c'était très raisonnable.
              
              GIT est surtout le fruit de la méthode de travail des développeurs du noyau.
              
              C'est comme ceux qui voulait persuader Linus d'utiliser svn alors qu'il avait clairement dit qu'il voulait du décentralisé.
              
              Le problème n'est pas technique, en terme de fiabilité, de rapidité ou de fonctionnalité.
              
              Chaque outils induit une façon de travailler. A partir du moment ou aucun produit ne correspond à la méthode de travail, un nouveau est créé.
              

              • [^]Re: Bazaar

                Posté par Nicolas Boulay () le 13/09/2005 à 11:50. (lien). Évalué à 2.

                il me semble que c'était Alan Cox qui testait monotone. Mais l'archives du kernel représentait un truc comme 2 Go de texte.

          • [^]Re: Bazaar

            Posté par Nicolas Boulay () le 13/09/2005 à 07:56. (lien). Évalué à 1.

            Dans ce cas, argumente un peu plus...

          • [^]Re: Bazaar

            Posté par Boa Treize (page perso, ) le 13/09/2005 à 20:48. (lien). Évalué à 1.

            Alors ça, c'est un troll de compétition !
            
            Du vrai troll à l'ancienne comme on n'en fait plus assez, des affirmations fausses mais crédibles balancées avec aplomb, des attaques ad hominem, la mention de programmes concurrents... Tout y est, tout marche, la preuve le commentaire est à +6.
            
            Zakath, je te tire mon chapeau ! (Et regrette de ne pouvoir dépertinenter ton commentaire qu'une seule fois.)

            • [^]Re: Bazaar

              Posté par Zakath (page perso, ) le 14/09/2005 à 13:02. (lien). Évalué à 1.

              Il semblerait que je ne sois pas le seul ignoble troll ici présent : http://lkml.org/lkml/2005/9/14/119/index.html(...)
              
              Les attaques ne sont pas ad hominem (même si Linus Torvalds est effectivement un con), simplement git et Torvalds sont indissociables puisque le second est le créateur et indéfectible supporter du premier, et que les choses ont l'air bien parties pour qu'il en fasse une question d'amour-propre, comme avec BitKeeper.
              
              Et d'ailleurs, je ne vois pas non plus en quoi le fait de dire que monotone et mercurial sont meilleurs que git fait de mon post un troll.

              --
              Vous devriez vraiment visiter Aperture First !

              • [^]Re: Bazaar

                Posté par Nicolas Boulay () le 15/09/2005 à 08:30. (lien). Évalué à 3.

                "Et d'ailleurs, je ne vois pas non plus en quoi le fait de dire que monotone et mercurial sont meilleurs que git fait de mon post un troll."
                
                Facile, tu argumentes pas, tu ne donnes aucunes explications. Tu condamnes juste.

                • [^]Re: Bazaar

                  Posté par Antoine () le 18/09/2005 à 12:10. (lien). Évalué à 2.

                  Mercurial produit une comparaison succinte ici :
                  http://www.selenic.com/hg/?cmd=file;filenode=b0166ba7a8977756db92a8(...)

                  • [^]Re: Bazaar

                    Posté par Nicolas Boulay () le 19/09/2005 à 16:38. (lien). Évalué à 1.

                    en gros, git a un repository plus gros. Mais rien d'autre sinon ?

                    • [^]Re: Bazaar

                      Posté par Matthieu Moy (page perso, ) le 02/10/2005 à 22:37. (lien). Évalué à 3.

                      > git a un repository plus gros.
                      
                      Attention, git permet maintenant aussi d'avoir un repository delta-compressé, donc du même ordre de grandeur de taille que celui de mercurial.

    • [^]Re: Bazaar

      Posté par Mickaël L () le 12/09/2005 à 11:10. (lien). Évalué à 6.

      GIT est écrit pour être super efficace sur un système de fichier utilisant le VFS de linux. Par contre, rien n'est garanti sur un autre OS. Si tu veux faire portable, tu peux, mais tu n'auras pas forcément les meilleures performances.

      • [^]Re: Bazaar

        Posté par Philippe Fremy (page perso, ) le 13/09/2005 à 18:15. (lien). Évalué à 6.

        Surtout, git est optimise pour les besoins de Linus. Le fait que CVS et subversions ne conviennent pas a Linus mais conviennent a des milliers de projets Open Source devraient deja donner un indice que git n'est pas pour tout le monde.
        
        Quelques points notables:
        - git stocke les fichiers integralement. Si tu changes une ligne a fichier texte de 50000 lignes, git restocke le fichier texte. CVS et consorts stockent un diff. Donc en terme de stockage, git n'est pas efficace et ce n'est pas son but.
        
        - git est concu pour avoir une notion de tracabilite tres profonde, sur l'integralite des sources et des changements d'un projet, le tout valide par une signature cryptographique (SHA). Il est possible en une seule operation de savoir si deux jeux de source git sont identiques ou differents.
        
        - git est optimise pour la notion de partage et de melange d'arbres differents, qui correspondent au modele de developpement du noyau : beaucoup de developpeurs avec des branches partielles (sous-systemes, experimentales) font d'abord des modifs dans leur branche avant de faire remonter la modif vers le repository de Linus.
        
        Bref, pas grand chose a voir avec les besoins classiques d'un SCM :
        - versionnement des fichiers
        - remonter dans le temps sur les versions passees
        - notion de branche
        - notion de marquage (tag)
        
        Apres, on peut rajouter d'autres fonctionnalites :
        - commit atomiques
        - renommage
        - utilisation en mode completement decentralise facon arch
        - interface conviviale
        - compacite du stockage
        - facilite de deploiement
        - portabilite
        - nombre d'outils et frontend associes
        - stabilite
        - dispoinbilite d'un frontend sous windows
        
        qui font qu'on aboutit a CVS, Monotone, subversion, arch, tla, bazaar, bazaar-ng, Super CVS et autres.
        
        Je sais que dans ma boite precendent, la convivialite etait un element fondamental. Si l'outil n'etait pas convivial, les developpeurs ne l'utilisaient pas et continuaient avec leurs zip sur un serveur partage. Chaque usage a ses criteres particuliers.
        
        Pour Linus, c'est git.

        --
        phil.freehackers.org

        • [^]Re: Bazaar

          Posté par Matthieu Moy (page perso, ) le 13/09/2005 à 18:40. (lien). Évalué à 4.

          > git stocke les fichiers integralement.
          
          Ça n'est plus entièrement vrai :
          
          http://git.or.cz/(...)
          Two, interchangeable, on-disk formats are used:
          * An efficient, packed format that saves space and network bandwidth.
          * An unpacked format, optimized for fast writes and incremental work.
          
          En fait, par défaut, il utilise la version "intégrale", et de temps en temps, on peut faire convertir explicitement dans l'autre format. Du coup, les dernières révisions (celles dont tu as vraiment besoin) sont accessibles rapidement, et les vieilles ne gaspillent pas l'espace disque, tout en restant accessibles.
          
          
          Pour info, il y a des gens qui sont en train de migrer de GNU Arch à git, et qui en sont contents (cf. les recentes discussions sur gnu-arch-users).

        • [^]Re: Bazaar

          Posté par Boa Treize (page perso, ) le 13/09/2005 à 20:37. (lien). Évalué à 2.

          Le fait que CVS et subversions ne conviennent pas a Linus mais conviennent a des milliers de projets Open Source devraient deja donner un indice que git n'est pas pour tout le monde.
          
          Grossière erreur de logique.
          
          Ceci dit, par ailleurs, git n'a jamais prétendu être pour tout le monde. Il ne prétend pas non plus être pour Linus et/ou Linux uniquement.
          
          git stocke les fichiers integralement. Si tu changes une ligne a fichier texte de 50000 lignes, git restocke le fichier texte.
          
          C'est faux. Git stocke une version compressée des fichier (compression zlib maximum).
          
          CVS et consorts stockent un diff. Donc en terme de stockage, git n'est pas efficace et ce n'est pas son but.
          
          C'est faux. Git peut stocker les objets sous forme compactée, et dans ce cas il est assez efficace en termes de stockage et encore tout à fait performant. Par exemple, Linux 2.6.11 avec son historique prend 191 Mo sous forme classique (chaque fichier étant compressé) et 62 Mo sous forme compactée. À comparer avec les 250 Mo des sources décompressées.
          
          - versionnement des fichiers
          
          Que veux-tu dire précisément ? Bien sûr que Git permet de retrouver les anciennes versions d'un fichier, même si techniquement ce n'est pas immédiat. Je ne sais pas si une commande existe déjà, mais conceptuellement je vois bien comment le faire : il faut remonter la hiérarchie des commits (donnée par git-rev-list), voir dans chaque arbre associé au commit si le fichier de même nom a la même signature SHA1. Si ce n'est pas le cas, tu as trouvé une ancienne version du fichier.
          
          - remonter dans le temps sur les versions passees
          
          Un petit coup de git-checkout permet de récupérer ultra-rapidement l'arborescence des fichiers telle qu'elle était à n'importe quel commit donné.
          
          - notion de branche
          
          Bien sûr. Git, comme tu le reconnais toi-même, c'est le royaume de la branche.
          
          - notion de marquage (tag)
          
          Bien sûr. En fait, n'importe quel objet peut être tagué. En général ce sont des commits qui sont tagués (pour marquer une version, typiquement), mais un arbre ou un fichier peuvent également l'être.
          
          - commit atomiques
          
          Je crois bien. De toute façon, vu que chacun bosse dans sa copie locale...
          
          - renommage
          
          Un point faible de Git, je pense. Pas facile de suivre à rebours l'évolution d'un fichier qui a changé de nom et de contenu. Trivial par contre de suivre l'évolution d'un fichier qui a changé de nom mais pas de contenu (merci SHA1).
          
          - utilisation en mode completement decentralise facon arch
          
          Bien sûr. C'est un des points forts de Git.
          
          - interface conviviale
          
          Le coeur de Git n'est pas convivial, et n'a pas à l'être. C'est de la plomberie. Pour la porcelaine, j'ai pas encore trop testé, mais gitk (explorateur de l'historique d'un projet) déchire grave, et git-web (même genre version html) déchire grave aussi. Cf. http://www.kernel.org/git/(...)
          
          - compacite du stockage
          
          Déjà traité, Git n'a pas à rougir.
          
          - facilite de deploiement
          
          Git est très simple et très léger, et ne requiert rien de bien méchant.
          
          - portabilite
          
          Git ne fonctionne effectivement pas (encore ?) sous Windows. Dommage. Il marche sous beaucoup d'Unix, y compris les versions récentes de Mac OS X.
          
          - nombre d'outils et frontend associes
          
          Ça évolue très vite. Cf. http://git.or.cz/(...)
          
          - stabilite
          
          Le projet n'a pas encore six mois, c'est clair qu'il bouge encore beaucoup. Mais qu'attendre d'autre au bout de seulement six mois ?
          
          - dispoinbilite d'un frontend sous windows
          
          Ah ben non, pas encore.
          
          qui font qu'on aboutit a CVS, Monotone, subversion, arch, tla, bazaar, bazaar-ng, Super CVS
          
          Aucun des programmes que tu cites ne répondent à tous tes critères. Donc, égalité avec Git ! :-) Par ailleurs, tu as oublié le critère de performance. Git déchire grave et vite à ce niveau, plus que ceux que tu cites je pense.

          • [^]Re: Bazaar

            Posté par Philippe Fremy (page perso, ) le 14/09/2005 à 15:53. (lien). Évalué à 2.

            Bon, je constate que git a evolue depuis que j'ai regarde de pres. Ca ne change rien au fond de mon argumentation, a savoir qu'il a ete developpe pour des besoins tres tres specifiques et qu'il ne peut ne pas convenir pour d'autres besoins specifiques aussi.
            
            Il y a des gens qui se disent que si le kernel utilise un truc, c'est forcement le meilleur truc au monde. C'est a moderer fortement, les hackers du kernel n'etant pas des etres humains normaux, mais des hackers du kernel.
            
            > Aucun des programmes que tu cites ne répondent à tous tes critères.
            
            Ce sont des criteres en vrac. De fait, mon argumentation est justement qu'il n 'y a pas de SCM universel pour l'instant.
            
            Dans ma boite mes deux commerciaux utilisent CVS quotidiennement sous windows grace a tortoise CVS. Ca ne serait possible ni avec arch, ni avec git, ni avec tla. Subversion serait envisageable. Malgre tous les inconvenients de CVS, c'est de loin une des meilleurs solutions par rapport a mon besoin.
            
            J'ai oublie d'ailleurs dans mes criteres la facilite d'utilisation. CVS, un utilisateur utilise quotidiennement deux commandes : commit update. Rien qu'en voyant la page de man de git, je laisse tomber. Il va me falloir deux heures pour comprendre de quelles commandes j'ai besoin et lesquelles ne me servent a rien.
            
            Et puis niveau stabilite, si la porcelaine evolue, ca ne convient peut-etre pas a tout le monde.
            
            J'ai regarde le mode pack mais j'ai pas trouve de description de l'operation de packing qui est faite derriere. Je ne peux donc pas dire si c'est efficace ou pas comme methode de stockage.

            --
            phil.freehackers.org

  • [^]Re: Bazaar

    Posté par Victor STINNER (page perso, ) le 12/09/2005 à 08:59. (lien). Évalué à 8.

    Hum, vous pourriez expliquer à des gens qui n'ont utilisé que cvs et subversion (les pauvres), comme moi, l'intérêt de faire des commit en local ? Pour moi, tout l'intérêt de SubVersion est de partager son travail avec l'équipe de développement ...
    
    Peut-être pour avoir un changelog plus précis que "hou là là, je sais plus !" ? :-) Ça m'est déjà arrivé ça, genre commit 2 semaines après et diff bcp trop long, aïe.
    
    Haypo

    • [^]Re: Bazaar

      Posté par LeMarsu (page perso, ) le 12/09/2005 à 09:09. (lien). Évalué à 9.

      Ben, c'est pas compliqué, imagine, tu travailles sur un très gros projet. Tu as un serveur distant, qui garde toutes les révisions. Tu dois rendre le projet bietot, et tu vas partir pendant je ne sais combien de temps dans un endroit sans le net.
      
      Avec subversion ou CVS, tu codes, tu codes, et tu commit un très très gros diff une fois que tu as récupéré le net. Les commentaires du diff seront douteux, et peu précis.
      
      Avec arch, svk ou autre décentralisé, tu commit en local sans te soucier de l'accès au net. Quand tu as fini tes grosses modifs (a raison de plusieurs commit), tu mets à jour le serveur distant pour que tout le monde en profite.
      
      Perso, j'apprécie beaucoup, dans mes voyages Lyon-Paris, 2h sans le net, ça veux pas dire 2h sans pouvoir commit...
      
      LeMarsu, qui espère avoir été clair.

      • [^]Re: Bazaar

        Posté par gnap gnap (page perso, ) le 12/09/2005 à 17:19. (lien). Évalué à 3.

        Ouais enfin à l'heure actuelle, là où tu n'as pas le net, y a pas mal de chance que tu n'ai pas l'électricité non plus !
        
        Je me rappelle avoir lu un message de Tom Lord qui déclarait que dans peu de temps, il n'existerait plus de serveur CVS et autres du genre, parce que tout se ferait en décentralisé.
        Il a apparemment raccroché le tablier avant d'avoir supplanté CVS... Ca ressemble un peu à une fable de Lafontaine qui parle d'ours...
        
        « Avec arch, svk ou autre décentralisé, tu commit en local sans te soucier de l'accès au net. Quand tu as fini tes grosses modifs (a raison de plusieurs commit), tu mets à jour le serveur distant pour que tout le monde en profite. »
        
        Mais est-ce que ça marche à ce point si bien que ça pour gérer les conflits ? Parce qu'a priori, si deux humains modifient les mêmes bout de code, la machine doit quand même avoir du mal à deviner quoi garder...
        Et si une solution miracle a été trouvée à ce sujet, à vrai dire, que ce soit décentralisé ou pas ne devrait rien y changer.

        • [^]Re: Bazaar

          Posté par Matthieu Moy (page perso, ) le 12/09/2005 à 18:55. (lien). Évalué à 4.

          > Ouais enfin à l'heure actuelle, là où tu n'as pas le net, y a pas mal de chance que tu n'ai pas l'électricité non plus !
          
          1) Y'a encore des gens qui ont une connection pas permanente. C'est sympa de faire plusieurs commit et de publier le tout en une fois au moment ou tu te connecte.
          
          2) Les pannes de réseau, ça arrive. Commiter en local, ça veut aussi dire être capable de commiter quand le serveur est planté.
          
          3) Qu'évoquent pour toi les mots "ordinateur portable" par rapport à la connection au net ;-) ?
          
          > Mais est-ce que ça marche à ce point si bien que ça pour gérer les conflits ?
          
          Un gestionnaire de versions, quel qu'il soit, ne remplace pas une bonne organisation. Ca t'aide, c'est tout. Si deux personnes modifient le même bout de code, il y a conflit, point. Un intéret d'un gestionnaire de version par rapport au merge à la main, c'est qu'il te dit là ou sont les conflits, c'est déjà ça.
          
          Avec un système centralisé, le conflit apparait au moment de l'update, avant le commit. Si l'update bousille ce que tu avais fait, c'est la galère (en général, tu as l'original des fichiers ou il y a conflit dans un coin, mais ça ne suffit pas forcément. Par exemple, tu peux avoir un update sans conflit mais qui ne compile même pas). Avec une branche par développeur, quand tu es content de toi, tu commit, et après, tu fais un merge. Si le merge casse tout, tu peux faire la différence entre ce qui vient de toi et ce qui vient du merge, c'est déjà ça.

          • [^]Re: Bazaar

            Posté par gnap gnap (page perso, ) le 13/09/2005 à 09:57. (lien). Évalué à 4.

            « Avec un système centralisé, le conflit apparait au moment de l'update, avant le commit. Si l'update bousille ce que tu avais fait, c'est la galère (en général, tu as l'original des fichiers ou il y a conflit dans un coin, »
            
            Disons que théoriquement, si tu dois avoir des conflits, c'est entre des branches (je parle de CVS là). Les commits fait sur un arbre principal ne devraient jamais crée de conflit si le projet est bien organisé.
            
            En gros, chacun fait sa branche à la maison, avec arch, si je comprend bien. Certes, il peut être interessant d'avoir une branche sans l'accès au net. Toutefois, il est aussi vachement commode d'avoir une branche sur un tronc commun, de manière à suivre le développement (en particulier si le merge n'est pas géré par l'auteur de la branche).
            
            Hormis les défauts habituels de CVS (dossiers ineffaçables, etc.), concrètement, en terme de gestion de projet, l'aspect révolutionnaire de la chose est assez discret. Finalement, il ressort surtout l'intérêt du *non connecté* avec le défaut du *chacun fait sa branche chez soi* (même si c'est à la mode de vouloir tout décentraliser, la centraliser permet dans un bon nombre de cas d'homogéneiser, de controler et de mieux superviser). A vrai dire, n'étant pas concerné par le *non connecté* (je ne suis pas un ultra-geek : la où il n'y a pas internet, c'est lorsqu'il est bon de faire autre chose que de tripatouiller un ordi... lire un bouquin par exemple... je ne suis pas du genre).
            
            Interessant, mais pas révolutionnaire :)

            • [^]Re: Bazaar

              Posté par or zax () le 13/09/2005 à 10:28. (lien). Évalué à 1.

              Le décentralisé n'est pas le point central, ni même une qualité, c'est un point de départ pour faire du distribué.
              
              Ce côté distribué te permet d'isoler de façon centralisé ou pas, certains efforts de développement.
              
              Exemple tu utilises une librairie version 1.5, le temps passe un la version 3 sort. Une fonctionnalité ou une correction de bug t'intéresse.
              
              avec la façon de travailler des outils distribués, cette ajout fait dans la version 3, sera dans une branch dédiée souvent.
              
              Toi tu ne vas pas tout migrer de la version 1.5 à 3 car trop de coût de migration.
              
              et bien avec un système distribué.
              
              Une ligne de commande unique et tu fais un backport tout seul. par exemple.
              
              Et ce n'est qu'un exemple. Ces outils n'ont pas vocation à révolutionner. par contre ils apportent beaucoup de souplesse.
              
              Pour ce qui est des conflits, ça ce gère très bien. les fonctions de merge étant très importantes pour des systèmes distribués, les merges sont particulièrements soignés et bien écris, parfois plus que dans pas mal de systèmes centralisés, donc les conflits apparaissent pas aussi facilement que l'on pourrait le penser.
              
              Autre point le coût de mise en place d'une infrastructure centralisé et distribué, il faut mettre des serveurs spécifique en place en centralisé, en distribué non donc gain en terme de coût (ps : le temps est aussi un coût, je ne parle pas forcément en terme monétaire).
              
              Bref le distribué c'est quelque chose de plutôt sympa, maintenant cela ne remplacera pas le parc actuel des systèmes centralisés, car le but est de proposer une plus grande diversité dans la façon de travailler, pas de tout casser. Des personnes ont écris des outils qu'ils auraient aimé avoir avant c'est tout.

              • [^]Re: Bazaar

                Posté par gnap gnap (page perso, ) le 13/09/2005 à 16:47. (lien). Évalué à 3.

                « Le décentralisé n'est pas le point central, ni même une qualité, c'est un point de départ pour faire du distribué.
                
                Ce côté distribué te permet d'isoler de façon centralisé ou pas, certains efforts de développement.
                
                Exemple tu utilises une librairie version 1.5, le temps passe un la version 3 sort. Une fonctionnalité ou une correction de bug t'intéresse. »
                
                « Distribué », c'est un nouveau terme pour que « décentralisé » paraisse toujours être une idée avant-gardiste.
                
                Parce que ce dont tu parles peut sans problème avec un système centralisé. Avec CVS, par exemple. Les tags et les branches, ça ne sert qu'à ça.
                
                Par contre, je demande à voir l'aspect réaliste de ton exemple : si ta bibliothèque s'incrémente de deux versions majeures, il est fort probable que ta fonctionnalité qui t'interesse repose des éléments n'existant pas dans le code que tu as toi.

                • [^]Re: Bazaar

                  Posté par or zax () le 16/09/2005 à 09:33. (lien). Évalué à 1.

                  tu peux faire du distribué sans forcément être décentralisé comme tu le dis si bien.
                  Si j'insiste sur le terme distribué, c'est uniquement par rapport au fait que dans ces systèmes là, tu créé des branches à tout va car c'est simple à faire, ça ne coûte rien en terme de stockage et ça te permet des merges avec une granularité plus fine.
                  
                  Par rapport à mon exemple c'est simple, plus l'écart de version est important, plus ton risque d'avoir des conflits est important. C'est le bon sens
                  
                  PAr contre si la fonctionnalité en plus repose sur d'autres fonctionnalités (avec d'autres branches etc ...) ça augmente la profondeur du merge c'est tout. Donc pas de problème. si la fonctionnalité est très simple et ne repose que sur peu de changement entre les deux versions, à ce moment tu ne fais pas un merge mais tu appliques juste le patch nécessaire.
                  
                  Sinon par rapport "« Distribué », c'est un nouveau terme "
                  un nouveau terme de quelque decenni, la notion d'informatique distribué c'est presque aussi vieux que l'informatique elle même
                  
                  "pour que « décentralisé » paraisse toujours être une idée avant-gardiste."
                  
                  Qui a dit que le distribué c'est avant gardiste, personne, la différence c'est que c'est une façon de travailler qui n'était pas courante dans RCS, maintenant les solutions existentes ont plus de variété.
                  
                  Monotone, Mercurial, Arch, Darcs etc ... ne font pas une révolution,ils facilitent certaines tâches c'est tout.
                  
                  La seule différence entre aujourd'hui et il y a quelques années, c'est que les gens utilisait CVS car c'était pratiquement le seul choix possible (sourceforge etc ...), maintenant il y a plus de choix, et ce qui resterons sur CVS, resterons dessus parce que ça répond à leur besoin, et non par obligation. A la rigueur cà c'est un énorme changement, et ça n'a rien avoir avec distribué ou pas, limite subversion a plus de mérite à ce niveau là.
                  
                  Donc tel produit tel caractéristique et tel produit tel autre ça avance à rien. Tel produit induit tel type d'utilisation ou l'autre produit aura sa logique d'utilisation, tu choisis celui que tu trouves le plus agréable. Si tu t'éclates avec CVS ou Subversion ou n'importe quel produit, personne ne te demande de changer.
                  
                  Maintenant, si tu veux comprendre l'engouement de certaines personnes pour bazaar par exemple, teste le, et là tu verras que l'utilisation n'est pas du tout pareil, après ça te plait ou pas ça ne regarde que toi. Maintenant Bazaar, Monotone, et compagnie ne font absolument rien de plus que CVS, car comme CVS ce sont des RCS et rien d'autre.

      • [^]Re: Bazaar

        Posté par golum () le 12/09/2005 à 22:53. (lien). Évalué à 5.

        Ce que tu indiques en parlant de commentaire est plus de l'ordre confort.
        
        Avec d'un système réparti où chacun dispose d'une archive en local et donc de la possibilité d'historiser plusieurs changements, c'est au niveau de la "gestion" des changements que tu as une plus value.
        Un projet informatique se decompose en général en une suite d'implémentation de certaines exigences ou demandes de changement identifiées (change request).
        Chacune d'entre elle se doit d'être historiser afin de la tracer et eventuellemenent de la repercuter sur d'autres branche (maintenance, ...)
        Avec un tel système tu peux prendre en charge plusieurs demandes alors qu'avec un système centralisé tu historises tous les changement en une seule fois au moment du retour sur le réseau sans différencier le code qui a permis de réaliser chaque changement.
        
        Après pour gérer les demandes de changements tu peux te contenter d'utilsre les commentaires ou t'integrer avec un outil de tracking.
        
        L'autre avantage est la possibilité de forker (par exemple parce que l'auteur d'un projet te refuse l'accès en ecriture) puis de réintegrer par la suite les modifications suivant les humeurs.
        D'ailleurs si on regarde l'historique de Arch et Bazaar on voit que cette souplesse facilite (encourage?) ce genre de pratique à bon ou mauvais escient.
        
        Vous avez dit Cathédrale ou Bazaar ?
        Le mythe revisité.

    • [^]Re: Bazaar

      Posté par champi (page perso, ) le 12/09/2005 à 09:11. (lien). Évalué à 5.

      Le commit en local ca permet de travailler rapidement sur ca version sans contraintes réseaux (travail dans le train, l'avion, ). Ca permet aussi une meilleure granularité en organisant le codage de nouvelles fonctionnalités en plusieurs commits puis en envoyant un "merge request" sur la ML de dev du projet pour que le developpeur qui maintient la branche officielle integre la fonctionnalité entiere d'un coup après tests et validation.
      
      Rien n'empeche de mettre un rsync dans un cron ou dans un post-commit hook pour mettre à disposition ses modifs sur un serveur http public au fur et a mesure de ses developpement quand un acces reseaux est dispo.

    • [^]Re: Bazaar

      Posté par Matthieu Moy (page perso, ) le 12/09/2005 à 10:27. (lien). Évalué à 10.

      Des intérêts, y'en a plein.
      
      Le plus gros à mon avis, c'est de pouvoir faire des commit réguliers qui ne dérangent pas les autres développeurs. Avec un gestionnaire de version centralisé et monobranche, on essaye en général de ne pas commiter si il y a eu regression. Avec Bazaar, ça m'arrive très souvent de commiter un truc que je sais être cassé, pour le réparer dans les commits suivants. Dans la branche principale, il n'y a pas de regression par contre.
      
      Un autre intérêt, c'est de pouvoir travailler vraiment en local. Pour une machine connectée au net, ça veut dire de meilleures performances. Pour un portable qui n'est pas toujours connecté, ça veut dire pouvoir faire des choses infaisables autrement.
      
      Un intérêt pratique est aussi pour la gestion des droits. Avec CVS/Subversion, un contributeur qui n'a pas les droits sur le repository est obligé d'envoyer ses contribution par patch. C'est la galère pour lui si il met du temps à mettre sa contribution au point et qu'il est obligé de faire des updates entre temps. Une solution est de lui donner les droits en commit sur le repository central, mais on n'aime pas donner les droits à n'importe qui non plus. Avec un gestionnaire de versions décentralisé, chacun a les droits sur son archive, et c'est tout. On peut travailler à plusieurs dans de bonnes conditions sans donner des droits à qui que ce soit (du moment que chacun a un bout d'espace web).
      
      Pour aller plus loin, la gestion de version distribuée est un très bon moyen de favoriser la revue de code, et de garder une branche stable vraiment stable. C'est le point clé qui permet le développement de Linux comme on le connait depuis la version 2.6: Une nouvelle fonctionnalité est développée séparément, testée dans différentes branches, soumises à sa majestée Torvalds, qui en général t'enverra bouler « ton patch, il est pas bien, faut changer ça, ça, ça et ça ». Les demandes d'améliorations sont faites sur la branche dédiée à la fonctionalité en question, qui est maintenue un phase avec la branche principale. Un jour, le code est estimé comme étant de qualité suffisante et est intégré à la branche principale.
      
      La gestion de version répartie, quand tu y as touché, tu as du mal à revenir à une gestion centralisée.

      • [^]Re: Bazaar

        Posté par MetalX () le 12/09/2005 à 12:16. (lien). Évalué à 3.

        Merci pour ta réponse très instructive.
        La gestion centralisée multibranche peut quand même être intéressante. Dans ma boîte, seuls les serveurs sont backupés quotidiennement, donc la meilleure façon de travailler est à mon sens d'avoir une branche par développeur. Cela revient un peu à ce que tu mentionnes dans ton premier point, mais je reconnais que c'est un cas particulier.
        En plus, comme tu le mentionnes, la gestion des droits est probablement plus simple.

      • [^]Re: Bazaar

        Posté par Bonnefille Guilhem (page perso, ) le 12/09/2005 à 13:42. (lien). Évalué à 5.

        Je ne comprends pas à quel moment intervient l'architecture décentralisée et à quel moment intervient l'organisation multi-branche.
        
        Je vois bien l'intérêt de pouvoir disposer d'un espace local sur lequel faire des commit lors des phases de dev. sans accès au réseau. Pour SVN (et CVS) il y a la notion de mirroir offerte par SVK.
        
        Coté multi-branche, SVN propose aussi ce mécanisme. Dans la doc officielle, il est même recommandé d'allouer des bracnhes aux développeurs lorsque la modification est un peu importante et peut nécessiter plusieurs commit avant stabilisation.
        
        Par contre, je crois qu'il n'est pas facile (bien que certainement faisable) de distinguer les droits d'un utilisateur "standard" et d'un responsable de branche (branche principale mais aussi branche de stabilisation/correction).
        
        Il me semble que la différence entre chacune des solutions réside surtout dans la taille du projet. Quelqu'un a des infos à ce sujet (genre "à partir de 20 dev. il vaut mieux bzr") ?

        • [^]Re: Bazaar

          Posté par Matthieu Moy (page perso, ) le 12/09/2005 à 16:53. (lien). Évalué à 3.

          En fait, la principale différence, c'est qu'en décentralisé, tu peux faire des branches distantes, donc, en particulier faire des branches chez toi sans demander l'avis de personne.
          
          Ensuite, sur la gestion des branches, c'est une grosse faiblesse de SVN : Il ne garde pas l'historique des merge, donc, quand tu fais un merge, c'est a toi de dire quelle version utiliser comme ancetre commun.
          
          Avec une gestion avancée des branches, tu dit "merge", et il se débrouille pour appliquer chaque patch une et une seule fois.
          
          Il faut voir aussi que la gestion centralisée est aussi possible avec des outils comme Bazaar. Le décentralisé est en général un surensemble du centralisé.

          • [^]Re: Bazaar

            Posté par golum () le 13/09/2005 à 19:17. (lien). Évalué à 2.

            Pour la mémoire de merge ca va venir.
            
            On en a déjà parlé là
            http://linuxfr.org/comments/573573.html#573573(...)
            et là
            http://linuxfr.org/comments/579101.html#579101(...)
            
            
            Sinon si la souplesse est un avantage du modèle décentralisé celui ci a aussi ses inconvénients.
            
            Pas facile de savoir où en est l'avancement des demandes de bug requests si chacun prend en charge 40 bugs dans son coin et commit sa branche une fois tous les 6 mois.
            
            De même pas facile de mettre en place un accès à une resource avec un jeton de reservation et ce afin de se prémunir du modification concurrentes. C'est uitle pour certains type de fichier qui ne supporte pas de gestionnare de merge (image, fichiers au format propriétaire, ....)
            http://linuxfr.org/comments/579260.html#579260(...)

            • [^]Re: Bazaar

              Posté par Matthieu Moy (page perso, ) le 13/09/2005 à 19:41. (lien). Évalué à 4.

              > Pas facile de savoir où en est l'avancement des demandes de bug requests si
              > chacun prend en charge 40 bugs dans son coin et commit sa branche une fois
              > tous les 6 mois.
              
              C'est clair. Je dis et je répète : un gestionnaire de version ne remplace pas une bonne organisation. Pour les bugs, je trouve qu'il est très important que la gestion des bugs soit centralisée. Idealement, le bugtracker doit garder trace de la personne responsable, de la branche dans laquelle c'est corrigé, et de la révision dans laquelle c'est intégré à la branche principale.
              
              Pour la gestion des bugs, le meilleur exemple de ce qu'il ne faut pas faire, c'est l'historique du développement de GNU Arch ;-) (des bugs ont été rapportés dans 3 systèmes différents mais n'ont jamais été corrigés).

      • [^]Re: Bazaar

        Posté par golum () le 13/09/2005 à 21:34. (lien). Évalué à 2.

        Un intérêt pratique est aussi pour la gestion des droits. Avec CVS/Subversion, un contributeur qui n'a pas les droits sur le repository est obligé d'envoyer ses contribution par patch. C'est la galère pour lui si il met du temps à mettre sa contribution au point et qu'il est obligé de faire des updates entre temps. Une solution est de lui donner les droits en commit sur le repository central, mais on n'aime pas donner les droits à n'importe qui non plus. ...
        
        Tu peux préciser ce point. Toujours en mettant à part le fait d'historiser des changements intermédiaires, en quoi est-ce différent d'un système centralisé ?
        Tu fais un checkout du repository,
        tu fais des modifs,
        tu updates de temps à autre
        et après soit tu commit parce que tu as obtenu les droits sur le repository soit tu envoies un patch.
        Avec un sytème décentralisé le pb est le même si tu n'as pas de droit en ecriture sur l'archive principale ?
        
        
        Le plus gros à mon avis, c'est de pouvoir faire des commit réguliers qui ne dérangent pas les autres développeurs. Avec un gestionnaire de version centralisé et monobranche, on essaye en général de ne pas commiter si il y a eu regression.
        
        Rien n'empêche de créer une branche par développeur et au moins le chef de projet voit où en est l'état d'avancement des changements que tu prends en charge.
        
        
        Un autre intérêt, c'est de pouvoir travailler vraiment en local. Pour une machine connectée au net, ça veut dire de meilleures performances. Pour un portable qui n'est pas toujours connecté, ça veut dire pouvoir faire des choses infaisables autrement.
        En disposant d'une copie de travail rien ne t'empêche de travailer en mode déconnecté, la seule limitation étant encore et toujours de ne pas pouvoir historiser de changements intermédiaires.(et encore c'est une feature qui devrait pouvoir être implémneté par clonage de working copy).
        Les seuls outils que je connaisse qui souffrent de limitation sur ce point car les copies de travail sont connectée en permanence avec le serveur sont Clearcase avec les vues dynamiques (et pas snapshot), Vesta( http://www.vestasys.org/(...) ) et Aegis ( http://aegis.sourceforge.net/(...) )

        • [^]Re: Bazaar

          Posté par Matthieu Moy (page perso, ) le 13/09/2005 à 23:47. (lien). Évalué à 4.

          La faiblesse de ce que tu propose, pour des petits projets, c'est le confort. Ne pas pouvoir commiter tant que tu n'as pas d'accès à l'archive, c'est casse gueule.
          
          Maintenant, pour un projet plus important, tu as des tas de cas ou ton système ne marche pas _du tout_. Imagine que tu as une contribution qui n'est pas encore intégrée à la branche officielle (pas encore assez bien testée), mais que tu veuilles déjà développer une deuxième fonctionalité qui l'utilise. Sans gestionaire de versions décentralisé, t'es mal.
          
          Autre exemple:
          - Bonjour, voici ma contribution (cf. patch joint)
          - J'y comprends rien à ton patch, coupe moi-ça en morceaux plus petits qu'on puisse s'y retrouver (réponse assez fréquente de Torvalds parait-il).
          - Ben, euhhh
          
          Encore un:
          - Les gars, j'ai commencé à bosser sur la fonctionalité X, vous pouvez tester ma branche située ici: http://www.../(...)
          - Pas mal. Moi, j'aurais bien mis Z à la place de T.
          - OK, je fais ça. Voilà, c'est commité.
          - Ah, ouais, c'est mieux. Tu peux changer U par V dans toto.c ?
          - Je m'en occupe et je publie ça.
          
          En un autre pour la forme:
          - Voilà, j'ai fait pleins d'améliorations pour le logiciel XYZ. Ma branche est ici: http://toto.com/branche(...)
          - Ah, tes patches 1, 12 et 42 m'ont l'air pas mal, je les intègre. Tes patches 33, 34 et 52 ont l'air pas mal, mais il y a X et Y qui ne vont pas. Les autres patches, j'en veux pas.
          - OK, je viens de créer une branche ( http://toto.com/monautrebranche/(...) ), j'ai pris seulement les patches 33, 34 et 52, et j'ai corrigé les problèmes X et Y. Ça va maintenant ?
          
          Mais, bon, tu peux argumenter que tu ferais tout ça avec un éditeur de texte et "cp -r". En effet, tu peux faire à la main ce que des outils te permettent de faire facilement de manière automatisée, y'a pas de scoop là.

          • [^]Re: Bazaar

            Posté par Matthieu Moy (page perso, ) le 13/09/2005 à 23:50. (lien). Évalué à 2.

            Autre point important : quand tu envoies un patch, tu ne peux pas garder l'historique des merge. Le mainteneur ne peut pas savoir facilement si le patch a été intégré ou pas après coup.
            
            Si tu envoies un deuxième patch qui est un surensemble du premier, et que le premier a déjà été appliqué, y'a conflit à coup sur.

            • [^]Re: Bazaar

              Posté par Bonnefille Guilhem (page perso, ) le 14/09/2005 à 08:43. (lien). Évalué à 4.

              Si tu envoies un deuxième patch qui est un surensemble du premier, et que le premier a déjà été appliqué, y'a conflit à coup sur.
              
              C'est bizare. De mémoire, le vénérable CVS savait déjà détecter qu'un patch/merge a été fait. Il détecte que les lignes sont IDENTIQUES et ne râle pas. Maintenant, dans des cas complexes (genre beaucoup beaucoup de modifs très proches), aïe aïe aïe.

            • [^]Re: Bazaar

              Posté par golum () le 15/09/2005 à 16:17. (lien). Évalué à 2.

              Ne confonds pas envoyer un patch et l'appliquer sur les sources avec le fait de merger entre deux branches.
              Si ta branche est déclarée (une branche pour tous les contributeurs non décalarés par exemeple), le fait de disposer d'une mémoire de merge ne dépend pas du modèle centralisé ou non.
              SVN l'intègrera en 1.4, Clearcase en dispose depuis l'origine (fl^che hyperlien de merge) et MetaCVS comble cette lacune de CVS (http://users.footprints.net/~kaz/mcvs.html)(...)
              
              Mais encore une fois dans le contexte opensource je conviens que le modèle décentralisé présente un intêret, pour intégrer des modifs d'un contributeur non déclaré.

              • [^]Re: Bazaar

                Posté par Matthieu Moy (page perso, ) le 16/09/2005 à 06:32. (lien). Évalué à 3.

                > Ne confonds pas envoyer un patch et l'appliquer sur les sources avec le fait de merger entre deux branches.
                
                Non, je ne confonds pas. Avec un modèle décentralisé, tu peux faire une branche chez toi sans rien demander à personne. Avec le modèle centralisé et les solutions que tu propose, tu n'as PAS de solution pour faire un merge, donc tu es obligé d'envoyer un patch.
                
                > le fait de disposer d'une mémoire de merge ne dépend pas du modèle centralisé ou non.
                
                Non, mais tu fais comment pour avoir une mémoire des branches que tu as fusionnées depuis une archive qui n'est pas l'archive principale avec un modèle centralisé ? (c'est justement ça la grosse différence entre les deux modèles)

          • [^]Re: Bazaar

            Posté par golum () le 15/09/2005 à 16:05. (lien). Évalué à 3.

            
            Maintenant, pour un projet plus important, tu as des tas de cas ou ton système ne marche pas _du tout_. Imagine que tu as une contribution qui n'est pas encore intégrée à la branche officielle (pas encore assez bien testée), mais que tu veuilles déjà développer une deuxième fonctionalité qui l'utilise. Sans gestionaire de versions décentralisé, t'es mal.
            
            Et pourtant mon "système" (1 branche par développeur + 1 pour l'intégration) a déjà été largement adopté dans le monde de l'industrie.
            Ca s'appelle UCM (Unified Change Management). Il s'agit d'une surcouche à Clearcase qui s'inscrit dans la démarche RUP d'IBM Rational.
            La branche (stream) d'intégration répertorie les baselines stables de la release courante du projet.
            Chaque developpeur prend en charge une ou plusieurs demandes de changements et les réalise dans sa branche propre. Lorsqu'il souhaite récupérer les dernières avancées stables (baseline) il effectue un "rebase" qui est en fait un merge amélioré de la branche d'intégration vers sa propre branche.
            Lorsqu'il a completé un certain nombre de changements, il les "delivre", c'est à dire qu'il effectue ou demande qu'on effectue un merge de sa branche vers celle d'intégration en ne prenant en compte que les changeset correspondant au demandes qu'il souhaite livrer.
            S'il souhaite développer une nouvelle fonctionnalité dans sa branche à partir d'un changement qui est n'est pas encore integré dans la branche principale rien ne l'en empêche.
            
            Le fait que la branche du developpeur soit sur un serveur distant ou en local n'affecte en rien le modèle.Il est de toute façon possible de deporter une branche sur un autre site avec Clearcase (Multisite).Ceci est d'ailleurs dynamique (transfert des droits d'ecriture sur la branche ) et différe des modèles décentralisé type Arch. (je peux developper si ca t'interesse)
            
            
            Autre exemple:
            - Bonjour, voici ma contribution (cf. patch joint)
            - J'y comprends rien à ton patch, coupe moi-ça en morceaux plus petits qu'on puisse s'y retrouver (réponse assez fréquente de Torvalds parait-il).
            - Ben, euhhh
            
            Ici tu soulignes le fait de travailler en mode pull.
            En décentralisé type Arch, un membre autorisé de l'archive centrale peut faire un pull de la branche du contributeur sans le déclarer puis merger la branche rapatriée sur la principale. En mode gestion centralisée, le contributeur doit être déclaré et travailler sur une autre branche du serveur ou une branche déportée.
            Je conviens que cette facilité corresponde mieux au dev Open Source type Linux. En entreprise, l'intêret est beaucoup moindre puisque tout contributeur est connu et qu'on doit tracer les changements qui lui sont affectés .
            De même en entreprise il est plus fréquent que ce soit le contributeur qui fasse le merge d'integration car c'est lui qui a la meilleur connaissance de ce qu'il touche. L'équipe d'intégration se contente de passer les tests d'integration, d'accepter ou de refuser de promouvoir la baseline.
            
            
            
            En un autre pour la forme:
            - Voilà, j'ai fait pleins d'améliorations pour le logiciel XYZ. Ma branche est ici: http://toto.com/branche(...)(...)
            - Ah, tes patches 1, 12 et 42 m'ont l'air pas mal, je les intègre. Tes patches 33, 34 et 52 ont l'air pas mal, mais il y a X et Y qui ne vont pas. Les autres patches, j'en veux pas.
            - OK, je viens de créer une branche ( http://toto.com/monautrebranche/(...)(...) ), j'ai pris seulement les patches 33, 34 et 52, et j'ai corrigé les problèmes X et Y. Ça va maintenant ?
            
            Rien n'empêche de faire la même chose en centralisé, du moment que le dev à les prérogatives pour créer un sous-branche.Cette technique s'appelle "branchement par activité". Elle permet entre autre de corriger un bug urgent en repartant d'une baseline antérieure alors que des fonctionnalités moins urgentes ont déjà eté développées.
            
            Désolé pour la réponse fleuve mais tu as abordé un peu tous les sujets.

  • [^]Re: Bazaar

    Posté par Sytoka Modon (page perso, ) le 12/09/2005 à 09:55. (lien). Évalué à 8.

    Même si je suis à 99% sous Linux, ma secrétaire, pas mal de maître de conférence, de prof et de thésards sont sous Windows. Il y a deux choses vraiment bien avec svn :
    
    -1- Un client Windows super (TortoiseSVN) stable et complétement intégré à l'explorateur de fichier. C'est vraiment facile à utiliser. J'ai amené pas mal de personne à utiliser un système de versionnement grace à ce client.
    
    -2- Une gestion transparente des fichiers binaires. C'était un des défauts majeur de CVS.
    
    Plus évidement pas mal d'autres défaut de CVS comme le fait de ne plus faire d'import sauf à l'initialisation du projet.
    
    Il est vrai que le fait de ne pouvoir commiter dans le train est vraiment génant pour les développeurs. C'est idiot que svn ne le propose pas car il a déjà un cache de tous les fichiers du serveur en local dans ses dossiers .svn (afin notament de pouvoir faire des diff sans contact avec le serveur central). Il devrait donc être possible de faire des commits différés.

    • [^]Re: Bazaar

      Posté par Antoine () le 18/09/2005 à 12:29. (lien). Évalué à 2.

      Il est vrai que le fait de ne pouvoir commiter dans le train est vraiment génant pour les développeurs.
      
      Tu peux utiliser svk qui est un front-end amélioré à SVN, et permet de créer un repository local en mode miroir (tu committes en local, et tu synchronises de temps en temps avec le repository distant). J'ai testé brièvement et ça marche bien. En plus ça suit l'historique des merges (svk smerge).
      http://svk.elixus.org/(...)

  • [^]Re: Bazaar

    Posté par golum () le 13/09/2005 à 21:54. (lien). Évalué à 2.

    BZr est vraiment un super système : simple et intuitif à utiliser, plus réactif qu'un subversion (car travail en local : pas de connexion réseau pour un commit)
    Sauf que tu est obligé de faire des pull /push avec l'archive distante après ton commit en local pour diffuser ton travail donc tu as bien des connexions réseau.
    Tu remplaces le cycle
    checkout-edit-update-merge-commit
    par
    checkout-edit-pull-merge-commit-push.
    Je ne vois pas en quoi c'est plus simple ni plus efficace en terme de réseau.
    
    
    En plus le code est en python, bien documenté et il est donc facile d'y contribuer ce qui rend ce projet particulièrement sain. Le jeu de tests permet d'organiserer régulièrement des refactoring de composant sans tout casser.
    
    Oulah Attention si Timaniac rôde dans les parages, tu vas déclencher un mag-troll sur la fiabilté des langages fortement typé vs typage dynamique

    • [^]Re: Bazaar

      Posté par Matthieu Moy (page perso, ) le 13/09/2005 à 23:51. (lien). Évalué à 2.

      C'est nettement plus efficace en terme de connection réseau parce que tu n'as besoin du réseau qu'un court moment aprés les actions en écriture sur l'archive. Toutes les opérations "read-only" peuvent se faire en mode déconnecté.
      
      Par ailleur, tu n'es pas obligé de te connecter à chaque commit. Comme le mec qui fait "check mail" avant de partir en voyage, qui réponds à ses mails dans le train, et qui envoie le tout en batch quand il retrouve sa connection au net.
      
      > checkout-edit-pull-merge-commit-push.
      
      Surtout pas. Un des gros intérêts du système décentralisé, c'est justement de ne pas mélanger un pull et une édition à la main.

Arch est le premier, mais pas le seul

• [^]Re: Arch est le premier, mais pas le seul

  Posté par Damien (page perso, ) le 12/09/2005 à 08:46. (lien). Évalué à 4.

  Je me suis mis à SVK aussi. Pour les aspects techniques (star-merge etc) je sais pas trop, je m'en sers pas... Par contre avoir subversion comme backend est un gros gros avantage: on peut utiliser des branches SVK chez soi même pour des projets avec un repository 'officiel' sous Subversion. Je crois qu'il y a moyen de mirrorer un projet CVS aussi, mais que c'est moins transparent qu'avec Subversion.

  • [^]Re: Arch est le premier, mais pas le seul

    Posté par Misc (page perso, ) le 12/09/2005 à 12:26. (lien). Évalué à 2.

    AU contraire, c'est très simple :
    voir le début ( à l'heure ou j'écrit ces lignes ) de doc sur :
    http://qa.mandriva.com/twiki/bin/view/Main/ForkingCvsWithSvk(...)

    • [^]Re: Arch est le premier, mais pas le seul

      Posté par Damien (page perso, ) le 12/09/2005 à 20:27. (lien). Évalué à 1.

      Ah c'est bon à savoir ça, j'en aurai l'utilité (merci l'INRIA :-)
      
      Je crois que je tenais cette idée du wiki SVK, qui n'est peut-être plus à jour :
      http://svk.elixus.org/?SVKCVS(...)
      
      PS. je me suis mis à SVK avec l'article de Scott Laird:
      http://scottstuff.net/blog/articles/2005/07/07/distributed-developm(...)
      http://typo.cdlm.fasmz.org/articles/2005/07/15/distributed-version-(...)

      • [^]Re: Arch est le premier, mais pas le seul

        Posté par Damien (page perso, ) le 13/09/2005 à 19:41. (lien). Évalué à 1.

        bon, en effet, je suis en train de mirrorer alexandria [1] ça a l'air de marcher, par contre...
        

        
        # this may ( will ) take a long time
        svk sync -a
        

        
        
        urf, en effet, it does o_O
        bon OK, rubyforge est ptet pas d'un répondant exemplaire non plus :-)

        • [^]Re: Arch est le premier, mais pas le seul

          Posté par Damien (page perso, ) le 13/09/2005 à 21:41. (lien). Évalué à 1.

          mouais ça fait quand même 2h qu'il est dessus là, pour un repo CVS d'à peine 1400 révisions...
          et il me fait des «Can't decode commit message as utf8.» de temps en temps aussi.

• [^]Re: Arch est le premier, mais pas le seul

  Posté par Matthieu Moy (page perso, ) le 12/09/2005 à 10:52. (lien). Évalué à 3.

  Oui, tiens, j'ai oublié de citer svk (jamais essayé, donc moi non plus, je ne jugerai pas).
  
  Pour la complexité de tla, Bazaar a quand même pas mal amélioré la situation. Pour un import par exemple, il n'y a plus que deux commandes (init-tree + import), et le message d'erreur si tu essaye de faire un import sans le init-tree, ou un commit à la place du import te dit quelle commande tu aurais du utiliser. Mais ça reste un gestionnaire de version assez complexe, c'est clair.
  
  Bazaar-NG par contre est franchement simple à utiliser. Il y a un système de plugins qui permettra de garder les trucs compliqués à l'écard des débutants (je vois ça un peu comme les extensions firefox). Par ailleurs, les développeurs sont des gens très compétents, je leur fait confiance pour nous faire un système excellent.

Tailor

Tant qu'on y est...

• [^]Re: Tant qu'on y est...

  Posté par Matthieu Moy (page perso, ) le 12/09/2005 à 10:59. (lien). Évalué à 2.

  J'ai joué un peu avec Darcs, c'est impressionnant de simplicité pour un débutant. Pour contribuer à un petit projet, j'ai lu un tutorial de 10 lignes, fait un get, des modifs en local, un "record" ou quelque chose comme ça, et "darcs send" a envoyé le tout par mail au mainteneur. Magique.
  
  Bazaar-NG adopte aussi le système "répertoire de travail = repository". Il faut quand même faire attention à une chose : dans ce système, une création de branche se fait par copie intégrale du repository, qui est une opération chère. Je ne sais pas comment Darcs gère ça. Avec Bazaar-NG, on peut faire une copie avec liens en dur sur les systèmes qui le supportent, c'est une première optimisation. Des gens travaillent sur un stoquage centralisé qui permettra de faire une branche rapidement, et sans gaspiller d'espace disque.

  • [^]Re: Tant qu'on y est...

    Posté par Antoine () le 12/09/2005 à 11:14. (lien). Évalué à 3.

    Des gens travaillent sur un stoquage centralisé qui permettra de faire une branche rapidement, et sans gaspiller d'espace disque
    
    C'est ce que font déjà Monotone et svk, à ma connaissance.

A ce sujet...

• [^]Re: A ce sujet...

  Posté par ham () le 12/09/2005 à 19:10. (lien). Évalué à 2.

  Au boulot on utilise le non-libre clearcase, qui n'est pas mauvais au niveau gestion de configuration, et marche bien en tant que système centralisé.
  
  Ce que je ne trouve pas c'est la gestion de configuration aussi détaillé[1] que le couple clearmake/clearcase, donc si un pro de darts, bazaar*,... etc sait si il y a des frontend, toussa ou des manière de faire la même chose, je suis a l'écoute
  
  [1]: la feature que j'aime bien c'est que quand clearmake fabrique un objet dérivé (résultat d'une action du makefile), il note les versions des fichiers utilisé, et la commande pour le faire.
  Si le collégue a produit un binaire, je peut savoir comment il l'a produit *exactement*, jusqu'a la versin des .h de la libc.
  
  J'aime bien ca parceque cela ne demanque aucun effort en plus.
  
  Je pense qu'en ayant des attributs sur les fichiers, ou les objets dérivé stocké de manière particuliere dans le gestionnaire de version, c'est possible, mais j'aimerais savoir si ca a été déja implémenté..

  • [^]Re: A ce sujet...

    Posté par golum () le 12/09/2005 à 23:29. (lien). Évalué à 5.

    ca s'appelle l'audit de fabrication, c'est une information qui est stockée dans le repository.
    
    Le problème c'est que dès que tu sors de ta vue (working copy) et que tu livres ton binaire, tu n'as plus cette trace.
    Donc 2 solutions soit tu fais bien gaffe as toujours labelliser ce que tu livres soit tu utilise le technique de timestamping (marquage des executables) pour enregistrer toute l'arbre des dépendance dans ton binaires.
    
    Autre avantage de clearmake. Clearmake est utilisé avec des vues dynamiques qui s'appuient sur un fs maison. Du coup toutes les accès à un fichier sont tracés? Donc quand tu compiles un .c qui fait apple à un include, clearmake detecte que le compilo ouvres le .h et ajoutes automatiquement dont une dépendance.
    Du coup tu n'as plus besoin d'indiquer explicitement la dépendance dans ton makefile.
    
    Autre avantage le partage d'objet dérivé. un binaire qui a déjà été compilé autre part dans le même contexte (même dépendance, mêm environnement) n'est pas regénéré mais directement recopié (lien symbolique) dans ton espace de travail (gain de temps et d'espace).
    
    Tu as aussi, la compilation des cibles en parallèle.
    
    Les inconvénients:
    Clearmake n'est utilsable qu'avec les vues dynamiques qui sont connectées en permanence avec le serveur donc uitlsable qu'en LAN ou WAN musclé.
    Avec les vues dynamiques tous les commits apparaissent instantanément (pas d'update) du coup ton environnemnt est suceptible d'être perturbé sans que tu le demandes (pb de correspondances des sources en debug, compil impossible, ....)

    • [^]Re: A ce sujet...

      Posté par Philippe Fremy (page perso, ) le 13/09/2005 à 18:27. (lien). Évalué à 2.

      A ajouter dans la liste des inconvenients : avec le salaire d'un administrateur ClearCase, tu peux embaucher trois developpeurs de plus.
      
      Dit autrement:
      - avec subversion/CVS, tu peux avoir un admin a temps partiel
      - avec ClearCase, il te faut deux admin a temps plein

      --
      phil.freehackers.org

      • [^]Re: A ce sujet...

        Posté par golum () le 13/09/2005 à 18:46. (lien). Évalué à 3.

        Désolé, mais vu l'interêt pour la gestion de conf en général et Clearcase en particulier un admin n'est pas mieux payé. (sauf consultant externe qui est une compétence rare et peu prisée)
        
        Pour le temps passé ca dépend de l'organisation. Avec toutes les possibilités de cet outil il faut bien baliser le sentier et appliquer la même gestion de conf sur tous les projets d'une même boite pour eviter de tout réinventer à chaque fois. C'est sans doute pour ca que ca cible en général des DSI de grande boites (processus qualité toussa).
        
        Et c'est rien comparé au coût des licences.

      • [^]Re: A ce sujet...

        Posté par MetalX () le 14/09/2005 à 03:08. (lien). Évalué à 3.

        Si c'est peut-être vrai dans certains cas, ce n'est pas une vérité générale. Chez nous, Clearcase était géré à temps partiel par un admin réseaux et un développeur. En moyenne, ça coutait donc grosso modo un demi-développeur ( pour une équipe d'une trentaine de personnes ). A cela, tu dois néanmoins rajouter le coût de la formation....

Discussion intérressante

[+] Jeu de mot

Après les journaux trollogène ...

• [^]Re: Après les journaux trollogène ...

  Posté par Matthieu Moy (page perso, ) le 12/09/2005 à 22:31. (lien). Évalué à 1.

  J'ai pas vu dans la doc que tu cites comment on crée une branche dans une archive distante.
  
  Bref, si tu lisait le texte que tu critiques ;-).

  • [^]Re: Après les journaux trollogène ...

    Posté par golum () le 12/09/2005 à 23:00. (lien). Évalué à 2.

    2e ligne
    
    Copy a file or directory in a working copy or in the repository.
    
    le repository est l'archive distante (il n'ya en au qu'une dans un système centralisé)
    
    et après le copy tu peux extraire une working copy de ta copie, donc tu travailles bien sur une nouvelle branche.

    • [^]Re: Après les journaux trollogène ...

      Posté par Matthieu Moy (page perso, ) le 13/09/2005 à 05:55. (lien). Évalué à 0.

      Distante par rapport à toi. Quand je parle de gestion distribuée, c'est évidament entre deux repositories distants l'un de l'autres. Ma phrase est peut être pas 100% claire, mais tu aurais pu me laisser le bénéfice du doute avant de crier au scandale.
      
      Par ailleurs, des branches, y'en a même en CVS, hein ...

      • [+] [^]Re: Après les journaux trollogène ...

        Posté par golum () le 13/09/2005 à 06:31. (lien). Évalué à -1.

        Désolé j'ai beau relire cette phrase je trouve toujours qu'elle s'applique parfaitement à des sytèmes centralisé.
        Tu indiques maintenat plusieurs repositories distants. Un système centralisé n'en à qu'un.Donc la différence n'est pas au niveau du branch and merge mais dans le fait que chaqcun dipsose d'un serveur sur sa machine.
        Pour la prochaine news tu pourras mettre que ça permet d'historiser plusiers changement à la suite sans accès au serveur comme c'est déjà développé dans les threadd plus haut.
        
        Sans rancune ;-)

Suivez la chaine

• [^]Re: Suivez la chaine

  Posté par golum () le 13/09/2005 à 19:38. (lien). Évalué à 2.

  Zut j'ma planté le premier maillon est plutôt là
  http://linuxfr.org/comments/579366,1.html(...)