CVS est de retour !

Posté par  . Modéré par baud123.
Étiquettes :
8
1
avr.
2010
Humour
Cela fait quelques temps que CVS n'a pas fait parler de lui. Il est vrai que ce projet tombait en désuétude : Dick Grune et Brian Berliner (les concepteurs de CVS) avaient exprimé l'idée de "passer à autre chose". C'est donc une nouvelle équipe qui a pris le flambeau. Elle a entamé une phase de réflexion profonde sur ce que devait devenir la gestion de code source au sein d'un projet.

Cette réflexion a été nourrie par les nombreuses demandes de la part de l'importante communauté CVS, ainsi que par des rapports de statistiques envoyés automatiquement par chaque appel à la commande CVS (une fonctionnalité non documentée rendue publique lors du départ de Brian).

Une nouvelle version de CVS, nommée CVS 2011, est donc en cours de réalisation afin de porter les fruits de cette longue réflexion.

Rien n'est encore finalisé, mais la nouvelle équipe se focalise sur trois points :
  • nettoyage du code et suppression ou simplification des fonctionnalités existantes
  • mise en place de concepts novateurs comme la gestion de source distribuée
  • création d'outils performants de migration
En ce qui concerne le premier point, les statistiques d'utilisation sus-citées ont montré que certaines fonctionnalités obscures comme les "branches" et les "tags" n'étaient pas particulièrement utilisées, quand bien même leur utilisation en a été facilitée par l'écriture de nombreuses documentations à ce sujet (voir http://ximbiot.com/cvs/manual/cvs-1.11.23/cvs_5.html#SEC54). Il a donc été décidé pour la version 2011 de CVS de rendre obsolète ces fonctionnalités, avant suppression. Conscient de la gène que cela occasionnerait pour certains projets, la transition se fera en douceur, avec une simplification du workflow. Par exemple, pour ajouter des modifications sur une branche, il faudra maintenant uniquement préciser le nom de la branche lors du commit :

$ cvs commit -j maBranche -m "Modifications apportées à la branche maBranche"
Checking in driver.c;
/usr/local/cvsroot/tc/driver.c,v
new revision: 1.2.2.1; previous revision: 1.1
done

En outre, une nouvelle commande "merge", permettra de fusionner plusieurs branches directement sur le serveur, sans intervention humaine. De quoi faciliter cette tâche toujours aussi pénible.

D'autres commandes seront purement et simplement abandonnées, comme la commande "blame", qui pourra être simulée en lançant quelques cvs up accompagnés de diff et de log. Le vocable "blame" ayant été jugé offensant par une partie de la communauté.

En ce qui concerne la mise au point de la version distribuée de CVS, il y a eu un différend entre l'idée originale de garder un mode centralisé et celle de se baser sur d'autres concepts plus ésotériques de "dépôt local" ou de "commit local". Les concepteurs originaux pensent que la chute du coût de la bande passante, ainsi que l'émergence d'appareils mobiles communicants (clé 3G, téléphones 3G, etc.) les confortent dans l'idée qu'un dépôt commun centralisé est une bonne chose. En effet, cela facilite le travail à plusieurs puisque tout le monde peut voir les modifications de tout le monde en temps réel. Les arguments de la nouvelle équipe ont néanmoins fait mouche lorsque la possibilité de travailler dans le train a été évoquée, Dick étant un fervent adepte de ce moyen de locomotion.

La nouvelle implémentation de DCVS (Decentralized Centralized Versionning System), dont l'utilisation reste optionnelle, permet d'obtenir un dépôt spécial à côté (et non pas à l'intérieur) de sa copie de travail, appelé "_REPOSITORY". Sans rentrer dans les détails, pour chaque commande DCVS, l'opération s'effectue dans le dépôt local (gain de temps). Une connexion est alors établie du dépôt local vers le dépôt central afin que celui-ci valide la commande (y compris pour les commandes comme diff, log, etc : la sémantique CVS est préservée). La communication des différences entre les différents dépôts locaux se fait comme à l'accoutumée, via une série de fichiers de patch que l'on pourra communiquer facilement (avec une clé USB par exemple). La mécanique a été prévue pour générer des patchs ne prenant pas plus de 1,44 Mo pour chaque fichier de patch.

Enfin, et c'est le point le plus important, afin d'attirer de plus en plus de monde vers CVS, la nouvelle équipe de développement a axé son travail sur l'écriture d'outils de migration facilitant la démarche de passage à CVS. On peut citer git2cvs, bzr2cvs, hg2cvs, svn2cvs, perforce2cvs et même msvisualsourcesafe2cvs. Bien sur, un cvs2dcvs permet de migrer vers un système décentralisé. Chaque outil a à sa disposition une pléthore d'options afin de peaufiner cette migration. Par exemple, l'option -j de la commande git2cvs permet de sélectionner la branche qui sera importée dans le nouveau dépôt CVS (pour le moment, git2cvs ne sait importer qu'une seule branche).

Toutes ces innovations permettront à CVS de redevenir le meilleur système de gestion de source. Linus Torvalds s'est d'ailleurs dit intéressé par une nouvelle migration du dépôt du noyau sous DCVS, d'où les efforts portés sur l'outil git2cvs. À n'en pas douter, l'année 2010 marquera le grand retour de CVS dans la course des systèmes de gestion de version distribués.
  • # J'ai failli y croire !

    Posté par  . Évalué à 0.

    J'avais pas vu la date...

    Bonne blague, en effet. Joli travail...
  • # continuus

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

    Utilisateur au quotidien d'un outil de gestion de version nommé continuus, est-il envisageable d'avoir un continuus2cvs ? Il nous manquerait peut-être la gestion de version des livraison (rien qui ne se gère pas sans les branches, pour ceux qui suivent la double négation, même si personne ne le fait (les branches pour ceux qui suivent)). Nous avons déjà géré le passage de SCCS à un vrai gestionnaire de version, l'évolution vers CVS est peut-être d'actualité (d'autant plus ?)
    • [^] # Re: continuus

      Posté par  . Évalué à 2.

      Utilisateur au quotidien d'un outil de gestion de version nommé cpold (1), est-il envisageable d'avoir un cpold2cvs ? Il nous manquerait peut-être la possibilité d'avoir tout l'historique d'un fichier à porté de main. Nous avons déjà géré le passage de DMZZ à un vrai gestionnaire de version, l'évolution vers CVS est peut-être d'actualité (d'autant plus ?)

      (1) http://roland.entierement.nu/blog/2008/01/22/cpold-la-poudre(...)
  • # Un oubli

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

    Je crois que vous avez oublié un des faits les plus notables de la dépêche originale. En effet, il y est dit que Google pense utiliser CVS 2011 afin de l'aider à porter son robot d'indexation sur Atari ST.
  • # Linus c'est le déterminant

    Posté par  . Évalué à 4.

    Je n'ai pas trop tiqué jusqu'à ce que je lise la mention de Linus à la fin :) . Excellente dépêche, bravo.
    • [^] # Re: Linus c'est le déterminant

      Posté par  . Évalué à 2.

      Moi j'ai buté directement sur le :
      "des rapports de statistiques envoyés automatiquement par chaque appel à la commande CVS (une fonctionnalité non documentée rendue publique lors du départ de Brian)."

      Mais est-ce seulement une blague???

      Bon sans rire, est-ce que quelqu'un audite les codes libre à la recherche de backdoor?
  • # Marre de tous ces SCM

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

    Devant la multitude de tous ces SCM « alternatifs » qui font du CVS en moins bien (svn, git, et autres mercurial ou bazaar pour ne citer que les plus connus), ça fait plaisir de voir que le SCM de référence continue à évoluer.

    CVS reste la référence, et ce n'est pas pour rien. C'est le seul à avoir sû garder des concepts fondamentaux comme la centralisation (on sait où sont les sources !), ou l'historique de chaque fichier. Ne parlons pas des performances inégalées jusqu'ici.

    En plus cette version 2011 va mettre tout le monde d'accord, en poussant la simplicité à l'extrême. J'en attends énormément.
    • [^] # Re: Marre de tous ces SCM

      Posté par  . Évalué à 3.

      Ils auraient pu pousser le concept de simplicité un peu plus loin. Ok, les branches n'existe plus, c'est très bien mais ce n'est pas suffisant car de l'autre coté ils rajoutent de DCVS. Et ça le merging reste toujours compliqué. Ils auraient dû le supprimer aussi!
      • [^] # Re: Marre de tous ces SCM

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

        Ils auraient pu pousser le concept de simplicité un peu plus loin.

        la réécriture de RCS est prévue aussi ;D

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Marre de tous ces SCM

          Posté par  . Évalué à 3.

          Notons que la réécriture de CVS a déjà eu lieu, et ce n'était même pas un 1er avril :
          http://www.opencvs.org/
          • [^] # Re: Marre de tous ces SCM

            Posté par  . Évalué à 2.

            OpenCVS c'est juste une implémentation "sécurisée" (et sous licence BSD) de CVS. C'est 100% compatible avec l'existant et sans nouvelles fonctionnalités
            • [^] # Re: Marre de tous ces SCM

              Posté par  . Évalué à 3.

              Ça reste passablement ridicule d'avoir réimplémenté CVS, qui a maintenant deux (gros) trains de retard sur l'état de l'art en matière de gestion de versions, et qui est bourré de défauts hormis les soucis de sécurité.

              C'est un peu comme s'ils avaient fait un serveur Gopher "sécurisé" au lieu de passer à HTTP.
  • # CPOLD vaincra !

    Posté par  . Évalué à 4.

    les VCS c'est bon pour les mauviettes qui ne se rappellent pas de ce qu'elles font.
    Moi, je retourne bosser avec ED, le standard EDitor !
    • [^] # Re: CPOLD vaincra !

      Posté par  (Mastodon) . Évalué à 3.

      ED, le standard EDitor

      Miranda (de Columbia Internet) code directement sur le support magnétique avec une aiguille de boussole : le pôle nord pour écrire un 1 et le pôle sud pour 0.
      • [^] # Re: CPOLD vaincra !

        Posté par  . Évalué à 2.

        tu fais comment avec un SSD ou un ramdisk ?
        • [^] # Re: CPOLD vaincra !

          Posté par  (Mastodon) . Évalué à 3.

          tu fais comment avec un SSD

          Avec un allume-gaz à quartz, mais très très petit.

          ou un ramdisk ?

          Avec des rayons cosmiques, ou un LHC très très très très petit.
  • # Poisson d'avril ?

    Posté par  . Évalué à 0.

    Poisson d'avril ?
  • # dès le titre on y croit pas

    Posté par  . Évalué à 3.

    :)
    • [^] # Re: dès le titre on y croit pas

      Posté par  . Évalué à 4.

      C'était le principe : plus c'est gros, plus ça passe :-)

      Il y a des morceaux de réalité, tout de même, dans la dépêche :

      - Dick Grune et Brian Berliner sont passés à autre chose depuis bien longtemps.

      - une réflexion sur la gestion de source est toujours en cours, ce qui a donné des outils comme git, par exemple.

      - il existe vraiment des outils comme svn2cvs ou git2cvs, mais ceux-ci ne servent qu'à la compatibilité arrière dans des cas qui sont, je pense, bien spécifiques.

      Le reste est complètement faux, évidemment.
      • [^] # Re: dès le titre on y croit pas

        Posté par  . Évalué à 1.

        Non, y a pas à dire, c'est bien tenté.
        Mais ayant été utilisateur de cvs et maintenant de don plus proche successeurs svn, j'y ait pas cru, c'est tout ^^

Suivre le flux des commentaires

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