Conférence Parinux : Les nouveaux systèmes de gestion de version

Posté par . Modéré par Amaury.
Tags :
0
7
nov.
2005
Communauté
Cet exposé présentera les nouveaux VCS, centralisés comme Subversion, ou décentralisés comme git ou darcs. Il vise un auditoire technique mais pas forcément uniquement des développeurs, ces outils pouvant également servir aux auteurs de documentation ou bien aux webmestres.

La conférence commencera à 19h30 le jeudi 10 novembre, elle se tiendra à l'endroit suivant :

Relais Ménilmontant
85bis rue de ménilmontant
75020 Paris Grâce entre autres à l'hébergeur SourceForge, l'utilisation de systèmes de gestion de versions (VCS, Version Control System, également appelés SCM pour Source Code Management) en réseau s'est largement répandue et ces systèmes sont désormais un des principaux outils de travail collaboratif. Fini, le travail solitaire du programmeur génial, dont le monde ne voyait rien avant la "release".
Plus faciles d'utilisation et plus répandus, ces VCS sont utilisés par les développeurs bien sûr, mais aussi par les webmestres pour gérer les fichiers qui composent le site Web, par les auteurs de documentation ou de support de cours pour gérer leurs documents, articles ou exposés, etc.

Pendant très longtemps, l'unique logiciel sérieux de gestion de versions était CVS. Il reste aujourd'hui la référence. Mais maintenant que le vénérable CVS atteint sérieusement ses limites et que la créativité bouillonne dans ce domaine, après dix ans de monopole absolu de CVS, on va s'intéresser à la concurrence.

CVS souffre en effet de plusieurs limites : les "commits" ne sont pas atomiques (en cas de disque plein, par exemple, on ne commite qu'une partie des fichiers), les répertoires et les méta-données (le fait qu'un fichier soit exécutable, par exemple) ne sont pas versionnés, le travail sur du code tiers, développé en amont, est très pénible (l'outil de CVS pour ce travail, les branches, étant lent et difficile d'usage). Enfin, le code n'est plus du tout maintenu.
Pour succéder à CVS, il existe deux sortes de VCS, centralisés ou décentralisés. Tous ont en commun de ne plus travailler par fichier, comme CVS, mais par "changeset" ou "patch", un ensemble de changement sur plusieurs fichiers.

Dans les systèmes centralisés, il y a un dépôt de référence et les utilisateurs lisent et écrivent uniquement dans ce dépôt. CVS est l'archétype de ces VCS. Mais désormais, sur ce créneau, il cède du terrain à Subversion. Ce dernier, baptisé "CVS++", tente de faire "CVS sans les problèmes". Par exemple, une petite révolution : on peut enfin renommer un fichier. Ou bien on peut enfin "versionner" les meta-données.

Les concepts étant les mêmes, les simples utilisateurs passent de CVS à Subversion en cinq minutes, d'autant plus que les commandes sont identiques. Pour l'administrateur, c'est plus difficile, car le changement est plus profond. Le format du dépôt est complètement différent (il en existe au moins deux, avec DB et avec des fichiers plats). La configuration d'un serveur réserve quelques pièges, on peut utiliser Apache 2 et WebDAV ou bien le plus simple svnserve.

Dans les systèmes décentralisés, le sujet chaud du moment, on essaie de mieux coller au mode de développement en réseau si fréquent dans le logiciel libre.

Dans ces VCS, il n'y a plus de dépôt de référence. Plusieurs dépôts coexistent et on peut lire et écrire dans celui de son choix.
Cela met fin au dépôt central sacré avec ses "commiteurs" privilégiés qui regardent les autres de haut. Le fait d'accorder ou de refuser le droit de "commiter" entraîne souvent des crises qui sont désormais inutiles.

La décentralisation permet plus facilement de suivre un logiciel amont, auquel on ajoute quelques patches qui ne seront pas forcément intégrés. Les VCS décentralisés dédramatisent ainsi le "fork", la scission, qui a secoué tant de projets de logiciel libre, en le rendant moins radical et moins définitif.

Elle permet enfin, ce qui est important compte tenu de l'explosion de l'utilisation des portables un travail en déconnecté (le portable contient un vrai dépôt). Les principaux représentant de la catégorie des VCS décentralisés sont Mercurial, SVK, monotone, git et enfin darcs, qui est le plus simple à utiliser.

Arch et sa mise en oeuvre la plus connue, tla, est l'ancêtre des VCS décentralisés. tla est très complexe à utiliser, mais il a néanmoins débayé le terrain et introduit le concept de décentralisation auprès de beaucoup d'utilisateurs, concurrençant sérieusement Subversion.

Plus récent, darcs est à la fois bien plus simple (comme CVS, on peut s'y mettre en quelques minutes) et plus matheux avec sa fameuse "théorie des patches" qui tente de donner un cadre théorique solide à la gestion des conflits entre dépôts décentralisés qu'on essaie de synchroniser. L'algorithmique mise en jeu par les VCS décentralisés est en effet bien plus complexe.

C'est darcs qui pousse le plus loin la logique des VCS décentralisés : toute copie de travail est un dépôt de plein droit. L'équivalent des branches de CVS, par exemple, est juste un autre dépôt.

Contrairement à Subversion, darcs n'est pas encore utilisé en production pour des gros projets mais il est très prometteur.

Aller plus loin

  • # Y'a aussi Bazaar 2

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

    Dommage de ne pas mentionner Bazaar 2 (alias Bazaar-NG, alias Bzr).

    http://bazaar.canonical.com/Bzr

    Il n'est pas encore tout à fait fini, mais il est proche de Darcs au niveau de l'utilisation (et en particulier de la simplicité d'utilisation).

    Une de ses grande forces, c'est son système de plugins (écrits en Python). Il permet d'avoir une base de code et un ensemble de commands pas trop gros, mais en permettant aux utilisateurs avancés de rajouter ce dont ils ont besoin en installant un plugin.

    Le projet est jeune, mais il y a une communauté très active derrière (une bonne partie des anciens contributeurs de GNU Arch, et plusieurs salariés Canonical à plein temps), il avance vraiment très vite.

    J'en profite pour faire de la pub pour le package Emacs qui permet d'utiliser bzr depuis Emacs (loin d'être fini, mais ça commence à marcher pas trop mal pour visualiser des diffs et commiter), successeur de Xtla pour ceux qui connaissent (il supportera aussi mercurial dans un futur proche si tout va bien):

    http://wiki.gnuarch.org/xtla#DVC
    • [^] # Re: Y'a aussi Bazaar 2

      Posté par . Évalué à 3.

      Et en attendant, il y a aussi baz (bazaar 1) qui remplace très efficacement tla.
      http://bazaar.canonical.com/FrontPage

      Perso, j'ai plus l'impression que bzr est un remplaçant de RCS (l'ancètre de CVS ?).
      • [^] # Re: Y'a aussi Bazaar 2

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

        > j'ai plus l'impression que bzr est un remplaçant de RCS (l'ancètre de CVS ?).

        Tu peux développer ?

        J'ai jamais utilisé RCS, mais je crois pas qu'on pouvais faire de merge d'un repository à l'autre, qu'il y avait un support http/sftp, un historique des merge, un opérateur de merge basé sur les "weaves" (comment on traduit ça ?), une selection des patchs section par section, une gestion des renommages correcte, des commit atomics ...

        Bref, à part le fait que l'archive est dans le répertoire de travail, qu'est-ce qu'il y a comme point commun entre RCS et bzr ?
        • [^] # Re: Y'a aussi Bazaar 2

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

          Bref, à part le fait que l'archive est dans le répertoire de travail, qu'est-ce qu'il y a comme point commun entre RCS et bzr ?
          le R /o\
        • [^] # Re: Y'a aussi Bazaar 2

          Posté par . Évalué à 2.

          J'ai pas du suivre l'évolution récente de bzr. Pas bien pour moi. Quand je l'ai essayé, j'avais l'impression d'être bloqué dans mon repository, et je n'ai pas trouvé de moyen simple pour mettre à jour depuis un dépot distant. Bon a priori, il y a maintenant bzr branch et bzr pull... On va dire que je n'ai rien dit, alors...
          • [^] # Re: Y'a aussi Bazaar 2

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

            Le "problème" de bzr, c'est qu'il a essayé d'être bien conçu avant d'essayer d'être fonctionnel. Du coup, forcément, les gens qui ont testé une version 0.0.x ont été un peu décu, mais ça évolue vraiment vite depuis.

            Aujourd'hui, je peux faire par exemple:

            $ bzr branch http://bazaar-ng.org/bzr/bzr.dev
            $ cd bzr.dev
            <hack hack hack>
            $ bzr commit -m "killer feature"
            # Récupérer les modifs de bzr.dev depuis le branch
            $ bzr merge
            $ bzr commit
            # publier mes changements
            $ bzr push sftp://shells.sourceforge.net/bla-bla-bla
            $ echo "tu peux merger" | mail auteur-de-bzr

            Plus tard, il y aura a priori un "brz send" comme le fameux "darcs send".

            En ce moment, Canonical est en train de faire sa migration en interne. Pour une idée de la quantité d'archives gérées, voir par exemple http://bazaar.ubuntu.com/ (pour l'instant, ces archives utilisent bazaar 1.x). La notion de gestion de version décentralisée est au coeur de la politique de Canonical et des idées de Mark Shuttleworth : le but est de favoriser la coopération entre les distributions. Quand ubuntu modifie un logiciel pour sa distrib, les modifications sont publiées en utilisant un gestionnaire de versions, c'est à dire proprement, avec un message de commit pour chaque modif, éventuellement plusieurs branches, et pas juste un gros patch. Bref, tout ça pour dire qu'il y a des exigences bien plus importantes que RCS derrière bzr ;-).

            Je trouve Bazaar 1 déjà très bon (mais trop compliqué pour les débutants, et pas assez rapide), tu peux te douter que Bazaar 2 a pour ambition d'être mieux.

            (ceci dit, le fait que bzr soit bien ne fait pas des autres des mauvais gestionnaires de versions)
    • [^] # Re: Y'a aussi Bazaar 2

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

      Je me doutais que la discussion allait surtout consister en remarques du genre "ya aussi XYZ 1.0 qui est super bien" :-)

      Il existe actuellement au moins une douzaine de VCS libres décentralisés. Monotone, darcs, tla 2, Bazaar-NG, Codeville, ArX, Fascist, svk, Mercurial, git/cogito... et j'en oublie.

      Le but de mon exposé n'était pas de faire une présentation de tous ces logiciels, d'autant plus que la majorité aura disparu dans deux ans (comme tla qui était super à la mode il y a deux ans et déjà en cours d'oubli).

      Je voulais au contraire sensibiliser les utilisateurs de CVS à l'existence d'autres outils, d'autres solutions. Ce n'est pas facile, surtout que le concept même de VCS décentralisé suscite des réactions aussi vigoureuses que le concept d'édition sans verrou de CVS il y a quinze ans.

      Donc, vous comprendrez que je ne tienne pas compte des messages du genre "Ouais, XYZ 1.0, C top k00l" :-) Ils ne sont pas du genre à rassurer ceux qui craignent de quitter CVS.
      • [^] # Re: Y'a aussi Bazaar 2

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

        Bon, oui, mais si on peu plus troller tranquille sur linuxfr !!!

        Plus sérieusement, évidemment que tu ne peux pas faire une présentation qui parle de tout les gestionnaires de versions, mais il me semble que bzr mérite d'être au moins mentionné, il a beaucoup de potentiel et pourrait être un de ceux qui ne disparaitront pas dans moins de deux ans justement.
      • [^] # Re: Y'a aussi Bazaar 2

        Posté par . Évalué à 3.

        Le but de mon exposé n'était pas de faire une présentation de tous ces logiciels, d'autant plus que la majorité aura disparu dans deux ans (comme tla qui était super à la mode il y a deux ans et déjà en cours d'oubli).

        Il est bien là le problème. On assiste à un début d'utilisation d'une multitude de systèmes, surtout en décentralisé, et on a aucune idée de ce qu'il en restera dans deux ans.

        Ils ont beau, pour certains, être 'facile' (j'ai du mal a mettre gnu arch et facile dans la même phrase, mais bon) à apprendre à utiliser, il n'en reste pas moins que maîtriser les commandes de 3-4 outils comme ca conduit à des erreurs (comme des svn delete qui effacent le vrai fichier en plus de celui sur le dépôt, au contraire de ce que faisait cvs...)

        Enfin bon, à dans deux ans pour savoir s'il y aura eu un peu d'écrémage...
    • [^] # Re: Y'a aussi Bazaar 2

      Posté par . Évalué à 2.

      Même si je crois beaucoup en bzr, je préfère attendre qu'il soit stabilisé et éprouvé par plus d'utilisateur. Ce qui vaut aussi pour les autres et ce qui revient à la remarque plus haut se demandant quels VCS de 3e génération vont survivre. Je suis sûr que bzr en fera partie.
  • # hg mercurial

    Posté par . Évalué à 4.

    A noter un autre VCS décentralisé libre, hg mercurial http://www.selenic.com/mercurial/wiki/ l'install et la prise en main est très simple. les changeset sont visible sur une page web (soit en utilisant un python-cgi, soit le serveur fournit avec)

    un article détaillé : http://lwn.net/Articles/151624/

    et une page du wiki http://www.selenic.com/mercurial/wiki/index.cgi/ConvertingRe(...) pour convertir un dépôt cvs en hg.

    Ca gère des gros projets ? oui, un dépot suit la branche du kernel linux est dispo sur kernel.org http://www.kernel.org/hg/linux-2.6/

    Moi, j'adooore.
  • # Inscription

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

    D'habitude, pour les conférences Parinux, il faut s'inscrire. Cette fois-ci, je ne trouve pas cette conférence sur le site de parinux [1] et de toute façon, je n'arrive plus à m'y connecter.

    Bref, on peut venir sans s'être inscrit ? je suis très intéressé.

    [1] http://parinux.org/activites/conf
  • # Personnellement

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

    Perso, c'est installation de subversion avec apache2 (https) pour pouvoir gérer les droits finement, ne pas avoir à faire de shell, et avoir éventuellement un repository accessible en anonymous.

    Par contre il est de plus en plus important d'avoir aussi un outil de gestion autour de celui d'historique, et pour le moment à part trac je ne trouve rien. Un truc qui gère les tickets, etc.

    Pour le moment mes configs c'est :

    - subversion avec apache2/https
    - le post-commit activé avec un mail pour tous les commits sur des listes privées accessibles aux développeurs
    - un trac pour gérer les tickets, avoir le repo accessible sur le web. Mais ce n'est pas idéal, trac necessite d'être sur la même machine que le repo svn, et la gestion des droits est assez chiante à mon goût.

    Et vous vous utilisez quoi pour la gestion de projets ?

    (C'est chiant que la conf soit dans le 20eme loin de chez moi, pour une fois que ça m'intéresse :)
    • [^] # Re: Personnellement

      Posté par . Évalué à 2.

      Pour moi c'est bazaar-ng et roundup. L'avantage c'est que ce sont deux outils (non liés actuellement) très simples à mettre en place et à utiliser. Ecrits en python, ils sont prévus dès le départ pour être personalisables aux petits oignons.
    • [^] # Re: Personnellement

      Posté par . Évalué à 2.

      taratata hmm
      on utilise svn + svk (http://svk.elixus.org/) ici
      pas de https, tout passe via ssh.. svnserve tourne pour les access anonymous..
      et viewsvn pour la vue online sans acces au repo direct.. par contre c'est lent, forcement, ca passe via svnserve.
      Ensuite un ptit script pour integrer les commits au bugtracker et pi vala (mantis)
    • [^] # Re: Personnellement

      Posté par . Évalué à 3.

      Je suis bien d'accord, les fonctionnalités et la philosophie du VCS c'est une chose, leur intégration à la gestion de projet en est une autre.

      L'approche de Trac me plait aussi sur le fond et pas sur la forme. Je me laisserais bien aller à lancer un projet qui constituerait une série d'extensions à un Wiki quelconque (au hasard MoinMoin) qui ferait l'interaction entre lesdits tickets, le VCS et les développeurs.

      L'idée est simple : un projet = des développeurs + un référentiel de source + des tickets catégorisés. Chaque page dédiée aux tickets alimente un flux RSS. Idem pour les commits et tout autre événement à rattacher au projet. Chaque développeur a sa vue, avec laquelle il peut se brancher sur les flux qui l'intéressent. Pour le reste, c'est un wiki ; donc la doc, les débats architecturaux et autres peuvent se réaliser dans l'outil en toute liberté. Notamment, chaque page peut référencer très simplement un ticket, un bout de code du projet...

      Il y a d'ailleurs l'outil Confluence d'Atlassian qui est basé sur cette idée. C'est hyper séduisant mais c'est ni libre, ni open source. Et puis, il faut s'équiper d'un serveur d'appli Java...

      Et vous ? Vous avez entendu parler de tels projets ?
    • [^] # Re: Personnellement

      Posté par . Évalué à 4.

      Heu t'as déjà jeté un coup d'oeil à scarab sur le même hébergeur que SVN (Tigris)
      http://scarab.tigris.org/
      • [^] # Re: Personnellement

        Posté par . Évalué à 2.

        J'ai parcouru sa doc mais je ne l'ai jamais utilisé. C'est clair que c'est tentant, comme eventum d'ailleurs ( http://eventum.mysql.org/wiki/index.php/Main_Page ).

        Je regrette toujours cependant de devoir passer par une appli web Java. Quant à l'intégration avec SVN, elle me semble encore bien légère :
        http://www.wever.org/java/space/java/Integrating+Subversion+(...)
        Notamment, rattacher les users du VCS à celui du bugtracker ne semble pas si trivial, et pourtant...

        Je regrette aussi que l'édition de bug ne profite pas de la simplicité et de la puissance qu'offre un wiki.

        En fait, je suis peut être un doux rêveur, mais je pense qu'un bon wiki bien outillé pourrait faire un parfait bugtracker[1]. Le problème majeur à résoudre à mon sens étant : la recherche de mots clés dans les bugs.


        [1] Soyons modeste tout de même : un parfait bug tracker pour PMP (Petits et Moyens Projets)
        • [^] # Re: Personnellement

          Posté par . Évalué à 2.

          Y'a quelquechose que je ne comprend pas dans ton cahier des charges.
          Tu regrettes que ce soit une appli Web Java et que ce ne soit pas un wiki.
          Mais tous les wiki que je connais sont des applis Web.
          C'est le coté java qui te gêne ou le coté client léger ?
          • [^] # Re: Personnellement

            Posté par . Évalué à 1.

            C'est le côté Java, mais je te l'accorde c'est pas très rationnel. Bien que les projets que je vise soient Java, va savoir pourquoi, ça me dérange d'avoir un Tomcat ou autre qui tourne sur le serveur... Sans doute que ça me rappelle trop le boulot.

            Allez t'as raison ! Je retire ce point-là. M'enfin, il nous en reste quelques uns tout de même :-)
  • # Diverses remarques

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

    C'est darcs qui pousse le plus loin la logique des VCS décentralisés : toute copie de travail est un dépôt de plein droit.

    C'est également le cas pour git et mercurial, qui ont repris cette excellente idée. Par ailleurs, comme Darcs, ils sont très légers à installer et à mettre en place, une autre évolution positive.

    Pendant très longtemps, l'unique logiciel sérieux de gestion de versions était CVS.

    ... dans le monde open-source. L'article ne le dit pas tellement c'est évident, mais il y a tout un tas de VCS propriétaires à côté desquels l'offre open-source à longtemps fait pâle figure. Bien sûr, il faut payer et supporter toutes les irritations d'un monde clos.
    • [^] # Re: Diverses remarques

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

      > mais il y a tout un tas de VCS propriétaires à côté desquels l'offre open-source à
      > longtemps fait pâle figure.

      Ah non merci, des outils dangereux (perte de données), non automatisables, stockant les données sous leur format (donc quand le serveur de licence est en panne, aucun moyen de les récupérer), des outils dont le seul avantage était le cliquodrome fourni avec ?

      Le domaine des VCS est un domaine où l'avantage des logiciels libres est net.
      • [^] # Re: Diverses remarques

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

        > Le domaine des VCS est un domaine où l'avantage des logiciels libres est net.

        Mouais. Va expliquer ça à Torvalds ...

        L'avantage est probablement en train de revenir aux logiciels libres, mais prétendre qu'il y a quelques années (ou hors CVS, point de salut), le libre devançait le propriétaire (on ne citera que ClearCase et BitKeeper), c'est un peu fort de café.
  • # (très) petit compte rendu

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

    J'y suis allé et franchement pas déçu. Effectivement, on n'y a pas trouvé une pelleté de descriptifs de chaque VCS décentralisé, et au final, ca ne manquait pas. Ca aurait alourdit une présentation que j'ai trouvé claire, pédagogique et objective, sans jamais partir en troll. Quelques détails techniques et des notions de mathématiques très abordables pour mieux comprendre les mécanimes de fonctionnement des gestionnaires centralisés ponctuaient la présentation.
    Je ne ferais pas l'affront à Stephane Bortzmeyer de résumer sa conférence car il l'a très bien fait dans cette dépêche, et ses slides, sous GFDL avec les notes du présentateur seront disponibles en ligne dans 3 à 4 semaines.
    La présentation s'est découpée en trois parties:
    - présentation et rapide historique des VCS
    - exemple de vcs centralisé avec Subversion
    - la nouvelle génération de vcs décentralisés avec darcs et git/cogito

    La conférence s'est terminé sur un petit débat d'une dizaine de minutes sur la gestion des merges et l'aide (technique et sémantique) que les outils pouvait ou pourraient apporter aux développeurs.

    Merci et bravo à Stéphane car tenir près de 2h, et répondre ensuite à toutes les questions de manière tout aussi compréhensible, ce n'est vraiment pas facile. J'en suis ressortit avec les idées plus claires.
    • [^] # Re: (très) petit compte rendu

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

      Je confirme, la conférence était très claire. J'en ressors avec l'impression que Subversion va vivre de belles années avant qu'un VCS décentralisé ne fasse l'unanimité. Pour l'heure, les prochaines années seront celles des migrations CVS vers SVN.

      Les concepts de VCS décentralisé ne sont de toute façon pas encore abordable pour la majorité des développeurs. On verra dans quelques années si l'idée a fait son chemin :-) je l'espère.
      • [^] # Re: (très) petit compte rendu

        Posté par . Évalué à 2.

        Pour quelles raisons les décentralisés ne sont pas abordables ? Il me semble au contraire, que de ne pas avoir à installer de serveur et gérer des droits d'accès rend les systèmes décentralisés beaucoup plus abordables. Plus besoin d'avoir un isp spécialisé : un simple site web http suffit, voir un compte mail...
        Je me souviens que lorsque tuxfamily a connu des problèmes il y a eu un engouement énorme pour les décentralisés, les mailings-lists de ces gestionaires ont connu immédiatement un afflux francophone !

        Souvent on trouve les systèmes décentralisés trop complexes parcequ'on regarde les fonctions avancées, mais il est tout à fait possible de se contenter des commandes de bases, et dans ce cas c'est bien plus simple que cvs ou svn.
      • [^] # Re: (très) petit compte rendu

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

        quelqu'un aurait il des notes ou des contacts avec la personne ayant organisé la conférence, pour une session de rattrapage ? J'ai eu du sommeil en retard et j'ai raté la conférence :-(

        Y avait il des visuels (présentations ooo ou autre ?) qui seraient diffusables, ou des liens ?
        • [^] # Re: (très) petit compte rendu

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

          Stéphane Bortzmeyer, le conférencier, a annoncé que les visuels, ainsi que les commentaires associés seront disponibles sous GFDL d'ici qqs semaines. En effet, il doit la présenter à une autre conférence pour laquelle ils demandent de ne pas la distribuer avant.

          Elle seront disponibles au moins sur le site de Parinux.

Suivre le flux des commentaires

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