Comparatif des systèmes de contrôle de version

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
10
fév.
2004
Communauté
Un article sur le site "OnLamp" fait le point sur les différents systèmes de contrôle de version disponibles en open-source, ainsi que BitKeeper en raison de son utilisation pour le développement du noyau Linux.

L'auteur revient rapidement sur l'utilité d'un système de contrôle de version (CVS étant le plus utilisé à l'heure actuelle) lorsqu'un projet atteint une taille importante et que le développement se fait à plusieurs.

Puis il liste les fonctionnalités communes à ces systèmes : commits atomiques, merge de branches, "repositories" distribués, renommage/suppression de répertoire/fichier avec conservation de l'historique du versioning... (désolé pour ce franglais mais les utilisateurs de ces systèmes me comprendront ;-) ).

ll présente enfin les avantages et inconvénients des systèmes suivants : CVS, Subversion, Arch, OpenCM, Aegis, Monotone et BitKeeper.

Une lecture conseillée à toute personne souhaitant travailler sur un projet à plusieurs développeurs et se faire une idée de ce qui existe pour cela en dehors de CVS.

Note du modérateur : j'ai rajouté le second lien évoqué dans une dépêche précédente.

Aller plus loin

  • # Re: Comparatif des systèmes de contrôle de version

    Posté par  (site web personnel) . Évalué à 9.

    On vient de parler de Subversion il y a quelques jours. Voici un lien qui a fait surface lors de la discussion, et qui est nettement plus informatif que l'article d'OnLamp lui-même :

    http://better-scm.berlios.de/comparison/(...)

    Quelques corrections en ce qui concerne l'article :

    * Arch commence à fonctionner sous Cygwin/Windows.
    * Même si Arch en version 1.1 est normalement stable, la version 1.2 apportera le support de l'intégrité et de la signature des archives (en mettant des hash MD5/SHA1 et des signatures PGP un peu partout), ce qui obligera à convertir ses archives existantes. Bien que cela ne doive pas poser trop de problème, moi je préfère attendre 1.2 pour me mettre sérieusement à Arch.
    • [^] # Re: Comparatif des systèmes de contrôle de version

      Posté par  (site web personnel) . Évalué à 2.

      Je suis en train de mettre sérieusement à Arch et effectivement la version 1.2 apporte des solutions au niveau de l'intégrité et de la signatures des archives (MD5 + signature du commit log via GPG).

      C'est un grand plus qui a été initié suite au "hack" qui avait eu lieu il y a quelques semaines dans le repository du noyau Linux.

      Au passage, je suis en train de créer le port de TLA (client shell pour Arch) pour OpenBSD pour la version 1.1. En espérant qu'il sera rapidement intégré à l'arbre des ports officiel.
    • [^] # Re: Comparatif des systèmes de contrôle de version

      Posté par  (site web personnel) . Évalué à 2.

      Effectivement, un excellent travail réalisé à l'URL indiquée.
      A noter l'existence d'un plugin subversion pour Eclipse, il s'appelle subclipse (http://subclipse.tigris.org/(...)). Je pense que je vais essayer ça dès que possible...
      • [^] # Re: Comparatif des systèmes de contrôle de version

        Posté par  . Évalué à 1.

        La derniere fois que j'ai regardee, il ne marchait que pour Windows :-(

        Extrait de la FAQ :
        "Why does Subclipse only support Windows?
        A linux version is planned. "

        Ca me freine beaucoup dans mon utilisation d'Eclipse+ subversion.
  • # Re: Comparatif des systèmes de contrôle de version

    Posté par  . Évalué à 4.

    désolé pour ce franglais mais les utilisateurs de ces systèmes me comprendront

    Ceux qui veulent apprendre ne comprennent pas forcément. Alors bien sûr il y a google sous le coude mais autant éviter un jargon qui peut être parfois rédhibitoire.
    • [^] # Re: Comparatif des systèmes de contrôle de version

      Posté par  (site web personnel) . Évalué à 4.

      Le plus simple aurait été de donner la version francaise... afin que ceux qui ne comprennent pas, le puissent :

      conservation de l'historique du versioning = conservation de l'historique des versions

      En plus c'était fastoche :^)
    • [^] # Re: Comparatif des systèmes de contrôle de version

      Posté par  . Évalué à 5.

      Ceux qui veulent apprendre ne comprennent pas forcément. Alors bien sûr il y a google sous le coude mais autant éviter un jargon qui peut être parfois rédhibitoire.

      le mieux c'est de comprendre la base cvs:
      http://www.freenix.org/curiosite/cvs.html(...)

      ca permet de voir que commit (commettre ?), merge (fusionner ?) et repositories (dépôts ?) ne sont pas incompréhensibles parce qu'ils sont en anglais, mais parce que leur sens est lié à leur cadre d'utilisation...
      • [^] # Re: Comparatif des systèmes de contrôle de version

        Posté par  . Évalué à 2.

        commit (commettre ?), merge (fusionner ?) et repositories (dépôts ?) ne sont pas incompréhensibles parce qu'ils sont en anglais, mais parce que leur sens est lié à leur cadre d'utilisation...

        Je n'en doute pas ! J'estime juste que dans le cadre d'une news, il serait bon d'être le plus explicite possible. Merci pour ton lien !
      • [^] # Re: Comparatif des systèmes de contrôle de version

        Posté par  . Évalué à 2.

        Dépôt et fusionner oui, commettre c'est quand même pas terrible... Dans ton lien ils proposent enregistrer, c'est mieux mais ça peut porter à confusion... Appliquer me paraît mieux. Quelqu'un voit d'autres candidats ?
        • [^] # Re: Comparatif des systèmes de contrôle de version

          Posté par  . Évalué à 1.

          reporter en configuration ? versionner (bof) ?

          Dans un SCM (comprendre Système de Gestion de Configuration), il y a pour moi x étapes :

          ° Pour un objet versionné (VO) : fichier ou répertoire
          - Créer/Référencer en gestion de configuration un VO : create ou mkelem
          - Editer un VO (pour le modifier <=> définir son contenu lors de la création) : checkout
          - Reporter en configuration une modification d'un VO : commit ou checkin
          - Détruire un VO : remove ou rm
          - Déréférencer un VO (supprimer toutes les références d'un VO) : rmelem

          ° Pour les opérations de gestion de versions :
          - Créer une branche de version : branch ou mkbranch
          - Fusionner deux versions : merge
          - Comparer ... : diff
          - Créer une étiquette (tag ou label) : mklbtype
          - Poser une étiquette : tag ou mklabel

          Et je dois en oublier... ,o)

          PS: quelques exemples de commandes fournis en italique (diffèrent selon les SCM ou ne sont pas toujours présents)
      • [^] # Re: Comparatif des systèmes de contrôle de version

        Posté par  . Évalué à 2.

        to commit (dans ce contexte) -> valider
        • [^] # Re: Comparatif des systèmes de contrôle de version

          Posté par  . Évalué à 0.

          Certainnement pas.

          To commit = Confier

          ça me parait un peu plus correcte vu que l'action consiste à envoyer les données modifiés au serveur. On pourrait aussi le traduire par envoyer je pense. Il n'y a aucun processus de validation la dedans.
          • [^] # Re: Comparatif des systèmes de contrôle de version

            Posté par  . Évalué à 0.

            Quand j'ai un problème de traduction, je vais voir http://w3.granddictionnaire.com(...)
            >>
            Le terme archiver désigne mieux cette opération complexe que les termes valider et soumettre, couramment employés, qui n'en recouvrent que partiellement le concept.
            L'utilisation du terme commit en français, comme dans faire un commit ou dans la forme verbale francisée commiter, est répandue dans Internet dans des sources d'origine française. Il s'agit d'un emprunt inutile à l'anglais to commit. Au Québec, cet anglicisme ne semble pas en usage.

            [Office québécois de la langue française, 2002]
            <<
            • [^] # Re: Comparatif des systèmes de contrôle de version

              Posté par  . Évalué à 1.

              Non, je ne suis pas d'accord, En l'occurence tu n'archive pas sur le cvs, ce n'est pas une archive du tout !!! C'est un endroit de travail ou le/les fichier(s) seront accessible de tous.

              Une traduction ce n'est jamais du mot à mot, il faut prendre le contexte et dans celui ci, "confier" correspond bien mieux.

              Et moi personnellement, quand j'ai un problème de traduction je prend mon "Larousse Français/Anglais".
          • [^] # Re: Comparatif des systèmes de contrôle de version

            Posté par  . Évalué à 0.

            Certainnement pas.

            Ah bon, vraiment ? Des références pour appuyer cette affirmation ?

            De mon côté, voici de quoi appuyer mon sentiment que l'expression to commit a transaction, puisque c'est de cela qu'on parle, soit couramment traduite en Français par valider une transaction:

            • Cours Supelec:
              http://wwwlsi.supelec.fr/www/yb/poly_bd/sql/poly_47.html(...)

            • Office québécois de la langue française:
              http://www.olf.gouv.qc.ca/ressources/bibliotheque/dictionnaires/Int(...)

            • Cours du CNAM:
              http://datom.dyndns.org/Cnam/cours(...) 2003 - 2004/Client Serveur/MT.pdf

            • Cours du LORIA:
              http://www.loria.fr/~skaf/cours/sybase/transaction/tsld055.htm(...)



            • Dois-je continuer ?



              To commit = Confier

              ça me parait un peu plus correcte vu que l'action consiste à envoyer les données modifiés au serveur. On pourrait aussi le traduire par envoyer je pense. Il n'y a aucun processus de validation la dedans.


              Je me permets de te renvoyer aux liens suscités pour apprendre les notions de transaction et d'atomicité, que visiblement tu ne maîtrises pas.

              La validation d'une transaction survient après avoir modifié des données au sein de cette transaction. Ainsi avec cvs, on n'effectue de cvs commit (validation de la transaction) qu'après un cvs {update, add, delete}

              Je te propose également de te renseigner un minimum avant d'affirmer des conneries. Il s'agit de vocabulaire technique, et ouvrir ton dico Anglais-Français pour espérer trouver la bonne traduction est illusoire. Le plus judicieux étant tout simplement de faire confiance à qqn qui a plus d'expérience que toi dans un domaine donné.
            • [^] # Re: Comparatif des systèmes de contrôle de version

              Posté par  . Évalué à 0.

              Faudrait peut-être aller chercher des définitions qui correspondent au contexte. Ce n'est pas en prenant la première définition venue sans se soucier du contexte que ce sera la bonne. C'est ce que fait un traducteur automatique, ou quelqu'un qui n'y connaît rien.
            • [^] # Re: Comparatif des systèmes de contrôle de version

              Posté par  . Évalué à 1.

              Effectivement, je me suis trompé (dans l'hypothése ou effectivement cvs effectus des tâches de vérification/validation/certification, je n'irais pas vérifier, je te fais confiance, cvs ne se contente pas d'inclure le fichier mais il effectue un processus de validation quelquonque, car sinon confier est plus approprié).

              Pour ton expèrience, désolé, j'suis pas sensé savoir que l'on doit croire sur parole et sans justification aucune ce que tu dis (proclame ?).

              Pour ton agressivité, admettons que ma phrase "Certainnement pas" t'es froissé. Admettons.
            • [^] # Re: Comparatif des systèmes de contrôle de version

              Posté par  . Évalué à 1.

              « De mon côté, voici de quoi appuyer mon sentiment que l'expression to commit a transaction, puisque c'est de cela qu'on parle, soit couramment traduite en Français par valider une transaction: »

              C'est une proposition connue, et qui n'est pas nettement meilleure que d'autres comme archiver, confier, appliquer. C'est un peu mieux que les traductions un peu trompeuses « mettre à jour » et « exporter » qui nécessitent de préciser que la cible est le dépôt, pas le répertoire de travail.

              Le problème, c'est que malgré ce que tu dis, tu fais bien de la traduction littérale : tu prends la même notion dans un domaine différent (les SGBD) et tu la traduis dans ce domaine là sans réfléchir. C'est compréhensible pour un admin de bases de donner (comme « confirmer »), mais il faut aussi apprendre à traduire, ce que visiblement tu ne maîtrises pas (pour te reprendre cette expression sympathique). Valider a bien d'autres sens, et c'est ce qui fait que ce mot est assez peu utilisé dans ce contexte, le franglais et des expressions plus longues sont employés pour éviter les confusions. Ça peut être une traduction mais c'est une traduction médiocre, donc si on se pose le problème de la traduction on ne s'en satisfait pas.
              • [^] # Re: Comparatif des systèmes de contrôle de version

                Posté par  (site web personnel) . Évalué à 1.


                C'est une proposition connue, et qui n'est pas nettement meilleure que d'autres comme archiver, confier, appliquer. C'est un peu mieux que les traductions un peu trompeuses « mettre à jour » et « exporter » qui nécessitent de préciser que la cible est le dépôt, pas le répertoire de travail.


                Valider est le terme le plus utilisé, parce que justement c'est la même notion que pour les SGBD, en effet on valide les changements effectués. Et c'est meilleur que "archiver" (qui ne vuet rien dire dans ce contexte, puisqu'on archive rien), et surtout que "confier" (qui ne veut absolument rien dire ici, quand tu fais un delete puis un commit tu ne confis rien au serveur cvs). Pour "appliquer" ça pourrait passer en précisant appliquer les chagements car appliquer est un terme très générique.

                Et je ne vois pas le rapport avec de la traduction littérale, c'est un terme technique, soit on a 1 terme officiel, soit on utilise le terme le plus usité, mais on ne met pas n'importe quoi parce que ça nous plaît, après pour se comprendre si chacun utilise le terme qui lui plaît on a pas fini (et c'est d'ailleurs pour ça, AHMA, que les gens gardent souvent le terme anglais ou sa francisation).
            • [^] # Re: Comparatif des systèmes de contrôle de version

              Posté par  . Évalué à 1.

              J'oubliais une chose : ce n'est pas parce qu'on crie (en écrivant en gras) que l'on a raison. Si le but est de convaincre, ce manque de respect provoque plutot l'effet inverse.
      • [^] # Re: Comparatif des systèmes de contrôle de version

        Posté par  . Évalué à 1.

        repositories (dépôts ?)
        la traduction plus ou moins officielle pour repository est référentiel, ce qui "rend" très bien les caractéristiques de la chose, et notamment l'aspect "référence" que constitue cet élément du système de controle de versions (alors qu'un dépôt a l'inconvénient d'être dans son sens plus statique, moins "intelligent", notamment par rapport au mécanisme de mise à jour avec fusion effectué à partir de cet élément).

        Pour commit, je proposerais du coup "envoyer", mais il est vrai que "valider" reste pas mal. Ceci dit, je ne suis pas sûr qu'il y ait tellement d'équivalents français pour le terme, et il serait peut etre sage à ce niveau de faire un enrichissement de la langue française, ce qui permettrait de discuter plus avant sur les bienfaits du commit de situation ou de répétition.
  • # Re: Comparatif des systèmes de contrôle de version

    Posté par  . Évalué à 3.

    Boaf, franchement, elle est pas terrible cette comparaison. Je trouve que celle-ci est bien plus exhaustive :
    http://better-scm.berlios.de/comparison/(...)
    (tous ces liens ont déjà été cités dans la news sur subversion RC1 http://linuxfr.org/2004/02/04/15330.html(...) )

    _pini.

    P.S. : tient, salut Fox, ça va ?
    • [^] # Re: Comparatif des systèmes de contrôle de version

      Posté par  . Évalué à 1.

      Ouuuuh ben je suis tellement lent qu'il y a déjà trois posts dont un avec le même lien...
      Je retourne me coucher...
    • [^] # Re: Comparatif des systèmes de contrôle de version

      Posté par  (site web personnel) . Évalué à 1.

      J'ai jamais dit que cette comparaison était la panacée. C'est juste un "must read" pour ceux qui veulent se mettre aux outils de versioning et penser à utiliser autre chose que CVS qui commence à être largement dépassé (Attention, troll detected)

      PS : oui ça va très bien Pini, faudrait qu'on se voit vu qu'on habite à 50m l'un de l'autre ;-)
      • [^] # Re: Comparatif des systèmes de contrôle de version

        Posté par  . Évalué à 3.

        « CVS qui commence à être largement dépassé (Attention, troll detected) »

        Ce n'est pas un troll, je pense que quasiment tout le monde est d'accord là dessus. Le problème c'est d'avoir des alternatives fiables (on doit y être tout juste) et répandues (sur les sourceforge-like notamment).
        C'est comme les autoconf/automake etc. Ça reste les meilleures solutions pour différentes raisons mais par bien des côtés ils sont « dépassés ». Dans leur cas il y a des alternatives mieux conçues mais qui ont d'autres inconvénients (par exemple des dépendances vers autre chose que make pour l'utilisateur final).
        • [^] # Re: Comparatif des systèmes de contrôle de version

          Posté par  . Évalué à 1.

          Tu as tout à fait raison pour CVS !!!

          Mais, puisque tu parles de autoconf/automake, est-ce que quelqu'un connait des alternatives ???
          • [^] # Re: Comparatif des systèmes de contrôle de version

            Posté par  (site web personnel) . Évalué à 2.

            Comme alternative a autoconf automake je te propose pmk :)
            http://pmk.sourceforge.net/(...) <= la

            voila voila

            pm
            • [^] # Re: Comparatif des systèmes de contrôle de version

              Posté par  (site web personnel) . Évalué à 1.

              Je crois me rappeler l'avoir essayé (mais ça ne m'a à l'évidence pas trop marqué), et il me semblait avoir compris que le principe était d'utiliser ce fameux programme 'pmk' pour interpréter le Makefile.in. Ça ne me plaît pas trop à vrai dire, car cela entraîne du coup une dépendance sur ce programme pour compiler le soft, tandis qu'un soft utilisant automake/autoconf n'a besoin que d'un shell (qui n'a pas beaucoup de chances d'être absent :-) Je vois bien des soluces, comme livrer un binaire statique dudit pmk avec le soft, mais c'est bancal : quid des gens utilisant une autre archi que la mienne ? Au moins, la soluce autoconf a l'avantage d'être universelle (même si c'est vraiment horrible d'obtenir un Configure.in indéboguable à souhait)...

              Envoyé depuis mon PDP 11/70

              • [^] # Re: Comparatif des systèmes de contrôle de version

                Posté par  (site web personnel) . Évalué à 1.

                Et, tant qu'on en est à parler des alternatives à autoconf, quelqu'un a-t-il essayé package-framework [http://freshmeat.net/projects/package-framework/(...)] ? C'est fait par le même auteur qu'Arch (je viens d'ailleurs de le découvrir à cause de ça :-) mais j'en sais pas beaucoup plus, il ne semble même pas avoir de page Web... Quelqu'un connaît ?

                Envoyé depuis mon PDP 11/70

              • [^] # Re: Comparatif des systèmes de contrôle de version

                Posté par  . Évalué à 1.

                Je crois me rappeler l'avoir essayé (mais ça ne m'a à l'évidence pas trop marqué), et il me semblait avoir compris que le principe était d'utiliser ce fameux programme 'pmk' pour interpréter le Makefile.in.

                Effectivement.

                Ça ne me plaît pas trop à vrai dire, car cela entraîne du coup une dépendance sur ce programme pour compiler le soft, tandis qu'un soft utilisant automake/autoconf n'a besoin que d'un shell (qui n'a pas beaucoup de chances d'être absent :-)

                Ca c'est en theorie, dans la pratique on a souvent besoin d'avoir autoconf sur le systeme. Il suffit de prendre un arbre des ports de n'importe quel BSD pour se rendre compte qu'il y a une dependance avec l'un des deux dans pas mal de ports. A choisir entre autoconf et pmk d'installe je prefere pmk car il est plus rapide et prends moins de place.

                D'un autre cote grace a pmk on se debarrasse du gros script shell qu'est "configure" (j'en ai deja vu qui depassaient les 10 mille lignes !!) qui peut etre une source d'ennui si quelqu'un de malicieux veut y introduire un troyan. Chose qui est deja arrivee plusieurs fois ...

                Et puis cote dependances il n'y a besoin que de pmk sachant que celui-ci ne necessite qu'un compilateur C et un shell. C'est donc loin d'etre si chiant que ca. En plus rien n'empeche de fournir un package contenant les deux solutions sachant qu'elles reposent toutes les deux sur le meme concepte de remplacement de tags.

                Je vois bien des soluces, comme livrer un binaire statique dudit pmk avec le soft, mais c'est bancal : quid des gens utilisant une autre archi que la mienne ?

                Ca n'est pas le but il me semble.

                Au moins, la soluce autoconf a l'avantage d'être universelle (même si c'est vraiment horrible d'obtenir un Configure.in indéboguable à souhait)...

                Effectivement, elle est universellement connue pour etre une source d'emmerdes. Plus serieusement je suis d'accord que l'idee de base d'avoir un script de configuration portable est sympa. Mais dans la pratique le dit script peut s'averer dangereux et comme dit plus haut on s'apercoit que finalement autoconf a souvent besoin d'etre installe sur le systeme.
          • [^] # Re: Comparatif des systèmes de contrôle de version

            Posté par  . Évalué à 0.

            Personnellement j'ai eu affaire à Ant, qui semble très bien (ceux qui l'utilisent en tant que développeurs sont en général enthousiastes) mais qui doit être présent sur la machine où se fait l'installation. Et comme il nécessite Java, j'avais trouvé ça très pénible (évidemment c'est moins genant pour ceux qui ont déjà Java).
  • # Pour plus d'info sur la gestion de configuration/version et le libre

    Posté par  . Évalué à 2.


    Au cour de mon DESS Qualité et sûreté de fonctionnement des systèmes informatiques, j'ai eu l'occasion de réaliser un mini-projet dont le sujet était «Gestion de configuration avec CVS».

    J'ai réutilsé les slides lors de la présentation que j'ai faite à Solution Linux 2004.

    Je suis preneur de tous commentaires/correctifs, et même d'une traduction en anglais.

    http://www.librapport.com/document.php?iddocument=45(...)
  • # Re: Comparatif des systèmes de contrôle de version

    Posté par  (site web personnel) . Évalué à 1.

    Bon en gros : Arch ou Subversion ?

    J'ai l'impression que selon les besoins la réponse ne va pas être la même. Quels sont les points forts de l'un et de l'autre ?

    "La première sécurité est la liberté"

    • [^] # Re: Comparatif des systèmes de contrôle de version

      Posté par  (site web personnel) . Évalué à 1.

      Un repository Arch est super facile à publier : il utilise HTTP, FTP, SFTP ou Webdav comme sous-jacent pour le stockage. Il suffit d'avoir un serveur configuré pour un de ces protocoles pour pouvoir héberger un dépôt Arch.

      Pour Subversion, c'est un peu plus compliqué car il faut configurer un serveur Apache2 (obligatoirement version 2) + module Webdav.

      Sinon, pour points forts/faibles, voir comparatif déjà cité plus haut dans les commentaires.
    • [^] # Re: Comparatif des systèmes de contrôle de version

      Posté par  . Évalué à 3.

      Une reponse (deja citee la derniere fois) en provenance d´une source objective :
      http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison(...)

      On y trouve une opinion interessante que je ne suis pas loin de partager :
      Opinion: I think the main reason why you would want to use Subversion is that it is an easy step from CVS. The development model (central repo, no locking, etc) is similar, and a developer experienced on CVS can be using Svn for basic operations in a matter of minutes. Subversion fixes a number of annoyances in CVS, including lack of renames and whole-tree commits, and is more pleasant to use than CVS. Svn is much less amibitious in scope than Arch, and missing major architectural features such as distributed branching. Subversion (as of 2003) is much better documented than Arch, which also makes the switch earlier.

      So: Subversion is an easier step from CVS. But if you're going to switch, maybe you should just go all the way to Arch.



      Plus generalement, si vous vous interessez a arch, ce wiki est excellent et de loin la meilleure documentation pour l´instant.
      http://wiki.gnuarch.org/moin.cgi/FrontPage(...)
  • # Re: Comparatif des systèmes de contrôle de version

    Posté par  . Évalué à 1.

    Il existe aussi DARCS que j'ai découvert récement, et qui semble très intéressant avec ses patchs sémantiques.

    http://abridgegame.org/darcs/(...)

    Si quelqu'un connait et a un avis sur la question, je suis curieux.
  • # Re: Comparatif des systèmes de contrôle de version

    Posté par  . Évalué à 1.

    Pourquoi BitKeeper a t il choisi pour faire a gestion de source de linux?

    C est l un des seul du comparatif a ne pas etre avec une license open source alors qu il semble y avoir des projets aux fonctionnalités équivalentes avec une license qui serait plus dans l esprit de l open source?
    • [^] # Re: Comparatif des systèmes de contrôle de version

      Posté par  . Évalué à 2.

      Parce que quand linus a commencé à utiliser bitkeeper, c'était le seul qui correspondait à ses critères (qui sont principalement la possibilité de developpement distribué, et un système de gestion de fusion de différentes branches en provenance de divers endroits très puissant). Aujourd'hui, je pense que arch pourrait convenir pour cela, mais n'ayant pas testé bitkeeper, il est possible que celui-ci soit plus performant/plus rapide que arch pour ce genre de scénario. De toute façon, à l'époque où linus a fait son choix, bitkeeper était probablement le seul outil viable pour faire ce qu'il voulait. Et même aujourd'hui, arch n'est pas assez mature pour un projet de la taille du noyau à mon avis.
    • [^] # Re: Comparatif des systèmes de contrôle de version

      Posté par  . Évalué à 3.

      L'auteur de BitKeeper travaillait sur Linux avant (et maintenant encore sans doute), il connaissait bien Linux et les problèmes de gestion de version spécifiques au développement du noyau. BitKeeper a été quasiment fait pour Linux (évidemment il convient pour d'autres projets) et c'est normal qu'il se soit retrouvé comme "meilleur" outil pour Linux (indépendamment de l'aspect libre). L'auteur a misé sur la réputation qu'il obtiendrait en étant retenu, il y a consacré du temps, et pour rentabiliser ce n'est pas libre. Mais si le critère libre avait été imposé dès le départ (si Linus avait dit que toute gestion de version devait se faire avec du libre) ce logiciel n'aurait a priori pas été créé.
      • [^] # Re: Comparatif des systèmes de contrôle de version

        Posté par  (site web personnel) . Évalué à 1.

        > L'auteur a misé sur la réputation qu'il obtiendrait en étant retenu

        Il a peut-etre aussi eu envie de pousser les developpeurs du noyau a utiliser autre chose que mutt + patch pour gerer le projet open source le plus populaire de la planete ? Je te trouve un peu reducteur dans le motivations de l'auteur.

        > Mais si le critère libre avait été imposé dès le départ ce logiciel n'aurait a priori pas été créé.

        pure extrapolation de ta part. Il y a deux ans, bitkeeper etait developpe et vendu alors que Linus ne l'utilisait pas. Bitkeeper aurait semble-t-il continue sa vie avec ou sans Linus. Le fait que Linus l'utilise lui a fait de la pub mais c'est tout.

        Pour ma part, je pense qu'il a cherche le meilleur compromis qu'il a pu entre liberte et rentabilite. Beaucoup critiquent, mais combien de ceux qui critiquent arrivent a vivre de logiciel libre (ou pseudo-libre).

        La licence est un peu bizarre mais en gros, si tu ne developpe pas un concurrent de bitkeeper et si tu publies tes sources, tu n'as pas de problemes pour l'utiliser ou le modifier.

        Je sais pas si tout le monde realise que Linus avait place la barre tes haut pour un outil de gestion de conf pour le noyau. Si le truc ne faisait pas minimum du reporting branche en branche (ou depot a depot) avec approbation des changements, c'etait meme pas la peine de lui proposer.
        • [^] # Re: Comparatif des systèmes de contrôle de version

          Posté par  . Évalué à 2.

          « Il a peut-etre aussi eu envie de pousser les developpeurs du noyau a utiliser autre chose que mutt + patch pour gerer le projet open source le plus populaire de la planete ? Je te trouve un peu reducteur dans le motivations de l'auteur. »

          Tu as coupé ma phrase, je ne parlais pas de la motivation pour réaliser le logiciel mais de ce qui a motivé le choix de la licence. S'il ne s'était soucié que du noyau et de ses développeurs, BitKeeper serait libre afin d'avoir l'adhésion de tous les développeurs. Certains développeurs du noyau ne seraient pas non plus interdits d'utilisation de la version gratuite de BitKeeper.

          « pure extrapolation de ta part. Il y a deux ans, bitkeeper etait developpe et vendu alors que Linus ne l'utilisait pas. Bitkeeper aurait semble-t-il continue sa vie avec ou sans Linus. Le fait que Linus l'utilise lui a fait de la pub mais c'est tout. »

          Il était évident que je parlais de BitKeepr tel qu'il existe aujourd'hui (ce qu'il était avant, ce n'est pas la question). Tu soutiens donc que la participation de son auteur à la LKML et l'utilisation de BitKeeper pour le noyau n'a strictement aucun effet sur son évolution, ses fonctionnalités, les outils associés, etc. ?

          « Pour ma part, je pense qu'il a cherche le meilleur compromis qu'il a pu entre liberte et rentabilite. Beaucoup critiquent, mais combien de ceux qui critiquent arrivent a vivre de logiciel libre (ou pseudo-libre). »

          C'est quelque chose que je n'ai pas critiqué dans mon post. Mais si tu comptes entamer cette question, il va de soi que l'argument selon lequel « les autres » ne font pas de rentabilité avec du libre ne vaut rien. Il fait le choix de sa licence. Le logiciel est propriétaire, ce n'est pas parce que l'auteur a fait ce choix pour telle ou telle raison que ça supprime les inconvénients habituels du logiciel propriétaire. La démarche est propriétaire, je ne suis pas sûr qu'il y ait grand chose à dire de plus...

          « La licence est un peu bizarre mais en gros, si tu ne developpe pas un concurrent de bitkeeper et si tu publies tes sources, tu n'as pas de problemes pour l'utiliser ou le modifier. »

          La première chose que l'on voit c'est que la liberté zéro n'est pas respectée. Même s'il y a de petits bouts des libertés suivantes, elles sont bien bancales. Pourquoi chercher à atténuer qu'un logiciel propriétaire est propriétaire ? Il peut avoir ses qualités mais il reste propriétaire, ça ne préjuge pas de sa fiabilité, de ses capacités et de choses comme ça...

          « Je sais pas si tout le monde realise que Linus avait place la barre tes haut pour un outil de gestion de conf pour le noyau. Si le truc ne faisait pas minimum du reporting branche en branche (ou depot a depot) avec approbation des changements, c'etait meme pas la peine de lui proposer. »

          Bien sûr Linus ne l'a pas choisi sans bonnes raisons. Mais est-ce que quelqu'un a contesté ce fait ?
  • # Format de stockage

    Posté par  (site web personnel) . Évalué à 1.

    J'aimerais poser une question à ceux qui ont utilisé Arch et/ou Subversion, sous quel format sont stockées les données ?
    RCS (non, c'est démodé ...) , DataBase, xml, autre chose ?

    Merci pour vos réponses/liens éventuels
  • # Re: Comparatif des systèmes de contrôle de version

    Posté par  . Évalué à 1.

    Pour ceux que ca interesse il y a actuellement un thread sur FreeBSD-hacker pour la migration de CVS vers subversion :

    http://lists.freebsd.org/pipermail/freebsd-hackers/2004-February/00(...)

    migrer un tel projet qui a 10 ans de CVS derriere lui n'est pas une chose qui s'improvise c'est d'ailleur juste une reflexion pour le moment.

    Autrement il y a perforce qui est utilisé pour certaines branches (trustedbsd par exemple).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.