Journal Quel gestionnaire de révisions pour un "débutant"

Posté par  .
Étiquettes : aucune
0
2
juin
2006
Bonjour à tous,

depuis bien des années, je fais de l'informatique et utilise des logiciels libres, mais mon boulot c'est de faire de l'admin système (et un peu de réseau), ça fait donc bien longtemps que je ne fais plus de prog (la fac...) mais passons...
En gros, j'aimerais savoir ce qu'il est mieux d'utiliser comme gestionnaire de versions, sachant que je suis un parfait newbie pour ce type de soft, je connais un peu (mais vraiment très peu) de CVS.
Sachant qu'il en existe énormément maintenant : CVS, Subversion, Bazaar, Bazaar-ng, Arch...

Mes contraintes, questions, besoins sont :
- logiciel libre bien évidemment
- facilité d'utilisation
- points positifs et négatifs des différents logiciels
- 'front-end' sympa (je pense par ex. à Trac pour Subversion)
- je ne sais pas quoi d'autre vu que je n'y connais pas grand-chose...

Pour l'instant, le truc c'est que je veux juste gérer un petit projet perso, mais mon idée c'est de pouvoir m'habituer à utiliser un gestionnaire de révisions pour un peu tout ce que je fais (scripts d'admin, fichiers de conf peut etre, etc.)

merci à tous.

  • # Subversion et Trac

    Posté par  . Évalué à 5.

    J'ai commencé avec ça et j'en suis très content. Je ne connais pas vraiment les autres gestionnaires de révision à part un peu cvs mais ce qui m'a franchement fait passer à subversion c'est Trac. J'y trouve toutes les fonctionnalités que je cherchais et en plus son interface est très sympa.

  • # Mercurial

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

    Mercurial est un outil de gestion de version simple écrit en python.
    http://www.selenic.com/mercurial/wiki/

    avec un tutoriel en français :)
    http://www.selenic.com/mercurial/wiki/index.cgi/FrenchTutori(...)

    Et en plus il est de base dans la future slackware ... bref que du bonheur ^_^

    • [^] # Re: Mercurial

      Posté par  . Évalué à 2.

      +1

      Mercurial répond à mon avis clairement à tes attentes :
      - libre
      - facile d'utilisation: très peu de commandes à retenir
      Points positifs: vitesse, légèreté, peu de dépendances, développement très rapide, mailing-list efficace et super état d'esprit.
      Points négatifs: encore quelques trucs à améliorer (pull sur certaines révisions via le réseau, push en HTTP, etc.)

      Il existe également un CGI pour mettre en ligne ton code, avec une interface à la gitweb.
      Que du bonheur ;)

      • [^] # Re: Mercurial

        Posté par  . Évalué à 1.

        Que vaut-il par rapport a bzr ? J'utilise actuellement CVS et darcs et je voudrais vraiment changer pour l'un de ces deux la: bzr ou mercurial.

        CVS est vraiment trop loudingue et je fais plein de boulette surtout depuis que je suis passé a darcs. Darcs est tres bien mais il est lent, vraiment tres lent et du coup le plaisir de l'utiliser pour sa simplicité est largement remis en cause.

        Je viens de tester tres rapidement et en surface mercurial et bzr, le point positif c'est que les commandes sont similaires a du CVS mais pour le cote BRANCHE, ca m'a l'air deja plus simple. Par contre, je ne sais pas si cela vient de moi ou quoi mais bzr m'a l'air super lent aussi en comparaison de mercurial (testé sur un meme repo avec un pauvre fichier).

        Alors, mercurial ou bazaar-ng ? J'aimerais bien votre avis sur la question.

        • [^] # Re: Mercurial

          Posté par  . Évalué à 1.

          Nan ca vient pas de toi, bzr est beaucoup plus lent. D'ailleurs je me demande comment les developpeurs bzr supportent cette lenteur sachant quand on voit le temps que ca met pour cloner leur repository.
          Sinon on dit que la principale feature que mercurial a et que bzr n'a pas est le 'warm tea': si on lance une commande, le thé est encore chaud quand la commande est finie.

          • [^] # Re: Mercurial

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

            En effet, bzr est vraiment plus lent que hg.

            Ceci dit, aucun des deux ne sont vraiment « terminés », l'équipe de bzr ne s'est pas tellement concentrée sur les perfs pour l'instant, mais c'est plus une question d'implémentation qu'une question de modèle, donc, on peut s'attendre à des progrès importants dans les prochaines versions.

            Par exemple, bzr n'a pas de serveur dédié. Gros avantage : on peut héberger une branch ou un repository bzr sur n'importe quel serveur, du moment qu'il y a du (s)ftp pour uploader et du HTTP statique pour downloader. L'inconvénient, c'est que du coup, le protocole n'est pas bien pipeliné, on n'exploite pas bien la bande passante. Le serveur dédié est sur la todolist de bzr.

            Autre différence : bzr est 100% python. L'intérêt, c'est que ça s'installe plus facilement. Sur un bzr fraichement téléchargé, ./bzr va marcher direct, rien à compiler. Ça simplifie l'installation sur les machines n'ayant pas de compilo C (souvent le cas sous Windows). Bien sûr, on perds encore en perfs, mais évidemment, il y a des gens qui se penchent sur la question, et maintenant que les fonctionalités de bzr sont à peu près stabilisées, certains développeurs font du profiling et ont commencé à voir ce que ça donne de surcharger certaines méthodes python par une réimplémentation en C, et les gains en perfs sont immédiats.

            Bref, aujourd'hui, hg est largement devant bzr niveau perfs, mais je ne vois pas de raisons pour que les deux ne deviennent pas à peu près équivalents d'ici quelques mois.

            • [^] # Re: Mercurial

              Posté par  . Évalué à 1.

              Ou alors tu peux utiliser le plugin hg pour bzr de Robert Collins :)

              Personnellement je comprends pas vraiment l'interet du "dumb server", la méthode que j'utilise c'est d'uploader des bundles (groupe de changesets) en general. D'ailleurs il y a un plugin (qu'il faudrait resurrecter) qui permet de creer ces bundles de facon efficace.

              La différence la plus grande entre hg et bzr pour moi, c'est que hg a été crée pour la simplicité (à la fois du design et de l'interface utilisateur) et la performance (Matt Mackall est dev kernel, il veut que son outil soit utilisable pour lui meme) alors que le premier souci des devs bzr c'est l'usabilité (avec souvent la question "comment integrer dans launchpad). Au final je trouve le code de bzr plus complexe et avec beaucoup plus d'indirections alors que le design de hg peut etre expliqué en quelques minutes (le principe des revlogs).

        • [^] # Re: Mercurial

          Posté par  . Évalué à 1.

          J'ai commencé par utiliser bzr qui me semblait réellement prometteur. Après avoir fait quelques patches avec sur un projet, j'ai choisi de tester hg.
          Raisons: vitesse principalement. Quand pour un pull il faut plusieurs minutes pour récupérer un projet, c'est très vite insupportable.
          Niveau fonctionnalités, je pense que pour le moment ils sont proches, bzr ayant un petit avantage avec quelques nouveautés.
          Il va y avoir une réunion entre développeurs Mercurial/Bazaar-NG prochainement, qui va permettre de rapprocher un peu les deux projets... peut être que quelque chose d'intéressant va en sortir !

          Sinon, pourquoi hg ?
          Encore une fois la vitesse: quand on développe, on a pas trop envie d'attendre une minute pour que le commit soit fait, puis encore 2 minute pour cloner le repo... du coup hg permet de travailler sans avoir une impression de "handicap" : le système de gestion de version aide plus qu'il n'énerve.
          J'aime bien par ailleurs son système de "hooks" (actions à effectuer à certains moments) qui permet par exemple pour un projet Web PHP/MySQL de faire un dump de la structure des tables SQL avant le commit : (precommit = mysqldump etc.).

          Encore un mot sur darcs: lent également (très variable peut être rapide sur certaines opérations et extrêmement lent sur d'autres), programmé en Haskell (dépendances ?) et un gros problème lors de tests sur son interface web: le temps de calcul pour faire un diff était tellement long qu'il y avait un "max execution time" à chaque fois... savoir que le serveur hébergeant cette interface pour darcs est un bi ou quadri proc 2Ghz...

          Conclusion: pour apprécier un système de gestion de version, il faut principalement qu'il soit discret (et pas trop verbeux), simple et intuitif.
          Pour ma part, j'ai abandonné Arch pour sa complexité, Darcs et bzr pour leur lenteur. Reste subversion sur lequel je ne peux me prononcer (segfault une fois, ça ne m'a pas mis en confiance et j'ai laissé tomber.)

          • [^] # Re: Mercurial

            Posté par  . Évalué à 1.


            réunion entre développeurs Mercurial/Bazaar-NG prochainement


            s/prochainement/le week end dernier/

            • [^] # Re: Mercurial

              Posté par  . Évalué à 1.


              Ouie, ces pré-vacances dans le sud m'on fait un peu déconnecter ...
              Merci de la rectification.
              Par contre, pas encore vu de feedback de la rencontre !

              • [^] # Re: Mercurial

                Posté par  . Évalué à 1.

                J'ai trouvé qu'on a eu des conversations assez interessantes, sinon pour le merge ca va dépendre de beaucoup de trucs. Je pense que Brian va faire un compte rendu complet dans les jours qui suivent.

  • # Conseils

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

    Bon, à éviter :

    - CVS (vieux, compliqué, pas puissant, ...)
    - tla/baz : beaucoup trop compliqués par rapport à ce qu'ils font.

    Parmis les stars du moment, il y a bzr (Bazaar-NG) et hg (Mercurial), qui sont tous deux très puissants, extensibles, mais quand même faciles d'utilisation (d'ailleurs, en passant : les équipes des deux sont en train de se rapprocher, il y a peu de chance que ça aboutisse à une fusion, mais il y aura sans doute des ponts entre les deux prochainement. Il y a déjà un plugin expérimental pour accéder à une archive hg depuis bzr).

    Dans le genre simple et puissant, il y a Darcs. Le gros point noir de Darcs est qu'il ne passe pas très bien à l'échelle, donc il n'est pas tellement question de l'utiliser sur des très gros projets, et ça a peu de chance de changer.

    • [^] # Re: Conseils

      Posté par  . Évalué à 1.

      pour bzr et hg, quand tu dis qu'ils sont tous les 2 très puissants, ça veut dire quoi ?
      qu'apporte-t-il de plus par rapport à subversion par ex. ? que ce soit au niveau des fonctionnalités (je pense que c'est de ça que tu parles) ou au niveau des frontends...

      (je regarde sur wikipedia fr en attendant... ah ! pas d'infos sur hg et bzr... tant pis !)

      • [^] # Re: Conseils

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

        Sur la gestion des branches, bzr et hg sont tous les deux _loin_ devant subversion.

        Première chose, ils conservent l'historique des "merge", donc, quand tu veux récupérer les modifications de la branche X que tu n'as pas encore, tu fais "bzr|hg branch X" et c'est tout, il se démerde.

        Deuxième chose, ce sont des gestionnaires de version décentralisés, ce qui veut dire que tu peux créer des branches d'un même projet sur des machines différentes. Quand tu bosses à plusieurs, chacun a sa branche, sur sa machine, et pas besoin de prise de tête avec un serveur centralisé à installer et à maintenir. Ça fait un peu peur au début, mais en fait, c'est à la fois plus flexible et plutôt plus simple comme façon de travailler.

        Après, il y a le fait de pouvoir stoquer les informations sur l'historique dans un sous-répertoire du projet, qui n'est pas toujours un avantage, mais bien pratique la plupart du temps. Par exemple, avec bzr ou hg, pour commencer un projet, tu fais "bzr|hg init": une commande et c'est tout (bien sûr, quand tu veux publier tes changements, il faut en faire un peu plus pour mettre ça sur le web).

      • [^] # Re: Conseils

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

        La principale difference entre bzr/hg et svn, c'est qu'ils sont distribués.

        Je suis au courant qu'il existe svk, mais je ne sais pas ce que le couple svn/svk vaut par rapport a des outils comme bzr ou hg qui ont été concu des le depart avec la notion distribuée.

        • [^] # Re: Conseils

          Posté par  . Évalué à 2.

          Je n'ai pas étudié le fonctionnement de SVK en détail mais voici ce que j'ai cru comprendre.(Je ne l'ai pas encore testé)

          SVK permet de répliquer un repository central en local. Ses branche sont mirrorées. Il permet ensuite de créer des branches sur la copie locale du repository qui ne sont pas mirrorées et des espaces de travail aussi bien sur un branche local qu'un branche partagée. Les commandes affectent tantôt le repository local et tantôt le local et le central. Cela permet donc d'effectuer un certain nombre d'opération sen local (commits successifs en mode déconnecté). Le problème que je vois est que toute la gestion est encore centralisée.
          Ainsi 2 développeur ne peuvent pas synchroniser leurs repository locaux sans passer par le repository central.Il faudrait tester pour vérifier si les commandes de pull et push peuvent s'adresser à d'autres repository que celui central.

          L'autre grosse différence que je vois avec les DVCS classiques se situe au niveau du commit sur une branche mirrorée.
          Avec un DVCS classique, il n'y a pas de branche partagée. Chaque developpeur est maitre de sa branche locale et il ne peut pas y avoir de versions concurrente déjà commitée par un autre developpeur qui empecherait le commit. Un developpeur est responsable de la branche de référence et il est le seul à merger dessus pour integrer les modifs des autres après synchronisation et recupération des branches des autres en lecture.
          Avec Svk le fait de commiter sur une branche répliquée envoie d'abord la modif sur le repository central puis resynchronise le repository local. Si une version concurrente a été commitée entretemps, il faut résoudre le conflit comme avec SVN.

          Cette architecture est inhérente aux outils centralisés. Ainsi Clearcase dans sa version multisite adopte un schéma semblable.
          Plusieurs serveurs hébergent un repository mirorré. Chaque serveur a l'exclusivité (masterchip) sur une branche.Et tous les espaces de travail du même site accèdent à la branche en concurrence d'accès comme un outil centralisé classique. Clearcase permet toutefois de transferer l'exclusivité sur une branche d'un site à un autre.

          En tout état de cause, l'utilisation de tels outils est plus complexe que celles d'outils nativement distribués.

          Pour ceux qui veulent approfondir SVK:
          http://pickscrape.woobling.org/svk-visual-guide.pdf
          http://svkbook.elixus.org/nightly/en/index.html

      • [^] # Re: Conseils

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

        J'oubliais : en parlant de front-end ...

        Subversion est clairement meilleur sur la quantité et la qualité des front-ends. En fait, Subversion part avec le gros avantage qu'il est le successeur de CVS, qui avait quasiment le monopole il y a quelques années. Du coup, il y a une communauté d'utilisateurs, et de développeurs de « produits dérivés » énorme, que n'ont pas encore des projets jeunes comme hg et bzr (aucun des deux n'est encore en version 1.0 au passage). Mais il y a fort à parier que ça va se développer rapidement ! (il y a un projet Summer Of Code pour une GUI à bzr, et déjà des bouts d'interface graphique à gauche à droite)

        Perso, je trouve qu'une GUI peut être pratique, mais qu'on apprend mieux avec la ligne de commande.

  • # Subversion

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

    Simple et puissant.

    Je l'utilise tous les jours pour mes projets de développement et pour gérer mon /home sur plusieurs ordinateurs.

    Pour le développement j'utilise subversion avec des hooks côté serveur vérifiant :
    - des règles de syntaxe et de style (logiciel style_checker)
    - si le message de log est rempli et s'il contient un ticket Trac

    Puis des hooks post-commit pour :
    - envoi d'un mail aux développeurs
    - Modification de l'historique du ticket dans Trac
    - Lancement d'un test automatique avec buildbot.

    Voir http://linuxfr.org/~DaOlivR/21622.html et http://olivier.ramonat.free.fr/svn_trac_buildbot/index_en.html pour des informations sur la mise en place de Subversion Trac et buidbot (pour l'automatisation des tests).

  • # Trac RO

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

    Oui, SVN c'est vraiment sympa. Attention toutefois : Trac est très bien aussi, mais ce n'est un front-end qu'en lecture seule (impossible de commiter dans Trac). Aussi bien soit-il, les commits devront être fait avec svn ou un front-end graphique local.

    La gelée de coings est une chose à ne pas avaler de travers.

  • # En résumé : Subversion pour faire simple ou Hg/Bzr pour faire puissant ?

    Posté par  . Évalué à 3.

    Bon, si je résume un peu ce que j'ai compris des commentaires précédents. Subversion étant le successeur désigné de CVS est LE truc à utiliser tout simplement pour avoir un gestionnaire de révisions simple, qui fait ce pourquoi il est fait, et qui doit normalement suffire pour des projets simples (peu de monde, peu de branches, etc...) ?
    Et Mercurial ou Bazaar-ng sont des outils très très puissants, permettant de gérer des projets complexes avec beaucoup de monde, et surtout décentralisés ?

    Je résume bien ?
    Bon, du coup, je sais pas trop quoi utiliser, mais ça me donne un petit aperçu des potentialités de chacun, et me permet de faire déjà un tri, il ne m'en reste plus que 3 en lice ;-)

    • [^] # Re: En résumé : Subversion pour faire simple ou Hg/Bzr pour faire puissa

      Posté par  . Évalué à 1.

      j'ajouterai en faveur de Mercurial (hg) que ses commandes sont clonées à partir des commandes CVS. Les outils sont très différents mais les commandes se nomment un peu pareil ce qui permet de rentrer rapidement dans l'outil quand on connait un peu CVS.

      exemple:

      add: add the specified files on the next commit
      annotate: show changeset information per file line
      clone: make a copy of an existing repository
      commit, ci: commit the specified files or all outstanding changes
      diff: diff repository (or selected files)
      export: dump the header and diffs for one or more changesets
      init: create a new repository in the given directory
      log, history: show revision history of entire repository or files
      parents: show the parents of the working dir or revision
      pull: pull changes from the specified source
      push: push changes to the specified destination
      remove, rm: remove the specified files on the next commit
      revert: revert modified files or dirs back to their unmodified states
      serve: export the repository via HTTP
      status, st: show changed files in the working directory
      update, up, checkout, co: update or merge working directory

    • [^] # Re: En résumé : Subversion pour faire simple ou Hg/Bzr pour faire puissa

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

      C'est pas tellement ma vision des choses, non. C'est plus une question d'organisation que de nombre de personnes. Subversion est utilisé par des très gros projets (KDE par exemple).

      À l'inverse, j'utilise bzr sur un projet à 2 personnes, et c'est que du bonheur aussi. Pas de serveur à installer, on travaille chacun sur notre compte, sans avoir besoin de donner de droits à l'autre (avec subversion, la méthode typique quand on a la flème d'installer un serveur, c'est de donner un accès complet aux autres en mettant leur clé ssh dans ton ~/.ssh/autorized_keys, c'est un peu moyen quand même).

      • [^] # Re: En résumé : Subversion pour faire simple ou Hg/Bzr pour faire puissa

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

        Un petit rectificatif. Pour Subversion, sans server (svnserve ou WebDAV) il n'y a pas besoin de donner un accès complet ! Il suffit d'un compte utilisateur par développeur ayant accès au répertoire subversion si on utilise svn+ssh.

        Tout le monde n'a pas besoin d'utiliser le même compte ! C'est d'ailleurs fortement déconseillé car cela empêche de tracer correctement qui a fait quelles modifications.

    • [^] # Re: En résumé : Subversion pour faire simple ou Hg/Bzr pour faire puissa

      Posté par  . Évalué à 6.

      La différence centralisé vs décentralisé tient plutôt au mode d'organisation.

      Un outil type CVS/SVN est très bien adapté pour le développement en entreprise ou la centralisation simplifie l'administration (sauvegardes, gestion des privilèges, ...) et renforce la sécurité (dev closed source).

      Pour un développement opensource dans lequels les contributeurs viennent de tous horizons et peuvent être occasionnels, le fait de donner un accès en ecriture sur le serveur central peut devenir handicapant.
      Pour récupérer des contributions, il faut soit ouvrir l'accès en écriture au repository, soit récupérer un patch et l'appliquer.

      Avec un DVCS (Distributed Version Control System) chacun possède une copie (partielle ou complète) du repository et se syncrhronise à l'envi avec les autres. Un contributeur occasionnel crée des versions dans son repository local.
      Les developpeurs du projet n'ont plus qu'à récuperer la branche du contributeur en synchronisant leur repository avec celui du contributeur et peuvent utilisant les commandes de merge/comparaison/historiques de l'outil. Ils n'ont donc pas à sortir de l'outil ni à donner de privilèges pour integrer des contrib occassionnelles.

      La contrepartie est que le modèle de developpement est dit user-centric. Au final une seule personne doit integrer ou approuver toutes les contributions des autres.
      C'est ce modèle de developpement qui convient à Linus Torvald pour le dev de Linux.

      Pour les outils centralisé le modèle est dit repopsitory-centric car plusieurs contributeurs déclarés peuvent travailler en concurrence sur la même branche et donc intégrer, tester valider sur la même version. C'est pour ca que ces outils proposent des mécanismes de concurrence d'accès de façon à ce que celui qui commite n'écrase pas le travail des autres. Le fameux commit/checkin qui peut échouer car il faut résoudre un conflit de merge (schéma de concurrence optimiste)

  • # Darcs

    Posté par  . Évalué à 4.

    Tu as aussi Darcs ( http://www.darcs.net/ ) qui est pas mal au niveau de la gestion par plusieurs développeurs d'un projet, en ayant un arbre principal et tu chope des patchs de plusieurs autres repository.

Suivre le flux des commentaires

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