Journal Gestionnaire de versions

Posté par  .
Étiquettes : aucune
0
21
avr.
2005
Bonjour,

je souhaite utiliser un gestionnaire de version pour développer en ligne certains projets (espérant de nombreux contributeurs ;-)). Conscient que CVS est vieillissant je compte utiliser GNU-Arch ou Subversion, mais j'avoue que je ne saisit pas les différences fondamentales de ces deux outils, je suis à l'écoute de toute suggestion pour faire un choix ?

Merci.

Camille.

  • # Suggestions

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

    * Subversion est conçu pour remplacer CVS. Au niveau des concepts, c'est le plus proche. Subversion, c'est aussi un serveur Apache, un protocole propriétaire, une base de données (à éviter de corrompre), donc une approche assez « lourde ». Subversion, c'est soutenu par des gros acteurs et développé par une « grosse » équipe, donc c'est pro, bien documenté, y'a une grosse communauté, etc. Par contre, Subversion reste sur un modèle centralisé, un seul dépôt, et soit tu fais partie de l'équipe de dev d'un projet et tu peux y écrire, soit (comme pour CVS) Subversion ne te sert que d'outil pour récupérer la version la plus à jour d'un projet. En tant que chef de projet, tu dois gérer les permissions d'accès et surveiller un peu ce que font les devs dans le dépôt.

    * Arch est conçu pour être complètement décentralisé. Tout le monde peut facilement créer son dépôt à partir du tien, développer un ou deux trucs (correctifs, nouvelles fonctionnalités), et toi ensuite tu peux aller choper la modif dans leur dépôt. Beaucoup plus adapté à un développement de type « open source ». Arch c'est un seul exécutable, pour le stockage c'est le système de fichiers qui est utilisé, pour l'échange de fichiers tout fait l'affaire (serveur HTTP, serveur FTP, serveur SSH, tout moyen de mettre des fichiers à disposition du monde suffit). Arch c'est aussi beaucoup de choses à apprendre (plein de commandes de bas niveau à combiner pour obtenir ce que l'on désire), une documentation pas toujours excellente (mais suffisante, quand même), un développeur principal que l'on aime ou que l'on aime pas (Tom Lord, une forte personnalité, un peu comme RMS), plusieurs forks qui se développent en parallèle (tla, baz, bazaar-ng). Puissant mais pas très facile d'approche.

    * Darcs est conçu de manière similaire à Arch (développement décentralisé, utilisation du système de fichiers, partage par HTTP, FTP, mail, etc.). Il a la particularité de se débarrasser du concept de dépôt stocké à part sur le disque (tout ce dont il a besoin est stocké dans un sous-répertoire du projet), et de pouvoir réordonner les patches (composant un projet) dans tous les sens, tout en gérant leur dépendance, bien sûr -- le résultat le plus important, c'est qu'il est facile de ne prendre que les petits bouts intéressants dans une branche ou un fork, et vu que c'est très facile de faire des « forks », c'est important. Darcs est très simple, très facile à comprendre, bien documenté, très agréable d'utilisation, et très puissant (vu sa simplicité). Il souffre de quelques problèmes de performance sur des très gros projets (1 Go de source...), mais la situation s'est très nettement améliorée ces dernières semaines. Enfin bref, Darcs c'est super bien.

    * Monotone, je connais pas trop, je crois que c'est bien aussi. Il utilise une base de données pour stocker les révisions, c'est le genre de truc qui me bloque un peu.

  • # Hebergement

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

    A noter :

    GNA! ( http://gna.org(...) ) propose de l'hebergement gratuit de projets libres (code, docs, organisationel) avec toutes les fonctionnalités d'un sourceforge + le support de subversion et de arch.

    A noter, il est aussi possible d'utiliser tout autre systeme de version qui a juste besoin d'un acces sftp et/ou http (sans serveur specifique) comme bazaar, bazaar-ng (pas encore fonctionnel mais progresse TRES vite et dans la bonne direction), ou darcs en utilisant l'espace de telechargement d'un projet gna.

  • # Moi aussi

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

    je cherche un gestionnaire de version ou une configuration de subversion:
    En fait je voudrais pouvoir gérer les droits avec des ACL, enfin du moins pouvoir gérer les droits en changeant tout simplement les droits sur le FS(et donc le support acl devrait être pas trop compliquer à implanter)

    • [^] # Re: Moi aussi

      Posté par  . Évalué à 1.

      Les droits d'accès basés sur les fs ne sont pas la panacée.
      Cà nécessite les droits root sur la machine et souvent pas mal d'administration

      Un vrai système d'ACL est celui qui est pris en charge par le gestionnaire de source , qui permet de définir des profils d'utlilsateurs (chef de projet, developpeur, intégrateurs, reviewer, ...) et dont l'administartion peut être déléguée.

      Tu en as un exemple ici
      http://www.opencm.org/(...)
      Ce projet était vraiment prometteur, dommage qu'il soit moribond
      Tu as aussi celui-ci
      http://www.spectrumscm.com/(...)
      (sapussaipalibreetcétrécher)

      De même, avec subversion en mode Webdav tu peut faire des trucs pas trop mal.

      Je ne sais pas pour les autres.

  • # comparatif tout fait + GUI + doc

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

    voilà voilà
    http://wiki.gnuarch.org/SubVersionAndCvsComparison(...)
    (c'est orienté vu que les gars de arch le disent eux-mêmes)

    Sinon pour subversion, je vais m'y mettre et comme infos diverses dont des GUI et docs j'ai trouvé :
    http://kde-apps.org/content/show.php?content=15338(...) eSVN is a KDE GUI for SVN
    http://rapidsvn.tigris.org/(...) [en] GUI tool for GNU/Linux
    http://svnbook.red-bean.com/(...) [en] book by O'reilly about SVN
    https://svnhost.gi.polymtl.ca/utilisationSVN.html(...) [fr] user guide for subversion (create repository...)

    Pour arch ça m'intéresserait aussi, vu que sur gna ya aussi...

    • [^] # Re: comparatif tout fait + GUI + doc

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

      c'est orienté vu que les gars de arch le disent eux-mêmes

      Pas forcément puisque c'est un wiki ouvert à tous. Je me souviens d'un moment (il y a un an environ) où un fan de Subversion venait quotidiennement ajouter le moindre truc bénéfique à Subversion en le plaçant au même niveau que des fonctionnalités plus importantes, et voulait enlever certains détails pas intéressants (de son point de vue bien sûr). Enfin bref, toujours lire plusieurs sources, et pas qu'une page d'un wiki...

  • # étude comparative

    Posté par  . Évalué à 3.

    là où je fais mes études, on a des projets à environ 10 personnes sur un an. Pour ça un gars avait fait une étude assez longue et c'est subversion qui sortait gagnant pour notre utilisation.

    Je n'ai pas tout lu mais j'utilise maintenant subversion depuis un peu plus d'un mois et j'en pense :

    -> le passage par le web, c'est vraiment pratique (firewall)
    -> la gestion facile des move et des delete ( par rapport à CVS qui est tout pourri sur ce point)
    -> le plugin eclipse subversion est très bien fait

    En espérant que ça a pu t'aider.

    • [^] # Re: étude comparative

      Posté par  . Évalué à 2.

      Ce qui manque le plus a SVN actuellement c'est le la mémoire des merge
      Si on travaille sur 2 branches en parallèle, svn ne garde pas de trace des derniers merge et on peut se retrouver avec le même patch appliqué plusieurs fois en des endroits différents du code.
      Pour contourner, il faut donc retenir soi même les versions correspondant au dernier merge et n'appliquer que les patchs depuis cette version.
      La mémoire de merge est prévue pour la 2.0 je crois.

      Un avantage de SVN est qu'il s'intègre bien avec des outils de suivi des demandes de changement (issue tracking).

      De même sa gestion des révisions est particulièrement astucieuse et efficiente.
      Svn historise le projet et lui affecte un numéro de révision.
      Chaque modification de fichier créé une nouvelle configuration (révision) mais tout se passe comme si tous les fichiers et répertoires inchangés etaient pointés par des liens symboliques et seul les fichiers modifié sont vraiment nouveaux . L'algorithme permet donc de créer un nouvelle branche de dev ou de répérer configuration (release) en O(n) à comparer à la lenteur d'autres outils y compris propriétaires comme perforce ou clearcase.

      Pour l'aspect distribué, il est prévu à terme d'en produire une version distribuée.
      On peut toujours développer dans son coin mais on ne peut pas historiser de version intermédiaire. Ca n'est vraiment un inconvénient que lorsque qu'on veut impléménter plusieurs changements à la suite et les livrer en un bloc.
      De même on peut toujours revenir au code initial en local sans accès serveur (svn revert)

      Si on veut vraiment une version distribuée, on dispose de svk.
      par contre il faut aimer hacker le perl si on veut contribuer

  • # Merci

    Posté par  . Évalué à 2.

    Merci à tous pour vos suggestions, je pense que des tests s'imposent encore pour tater la réalité de la chose.

    Merci.

    Camille.

Suivre le flux des commentaires

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