mardi 18 novembre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de mammique :

Journal : Gestionnaire de versions

Posté par mammique (Jabber id, page perso, ) le 21 avril 2005
0
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.

> Lire le journal (20 commentaires, moyenne: 2,7).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Suggestions

Posté par Boa Treize (page perso, ) le 21/04/2005 à 06:32. (lien). É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.

  • [^]Re: Suggestions

    Posté par vieuxshell () le 21/04/2005 à 08:44. (lien). Évalué à 3.

    une base de données (à éviter de corrompre)

    Depuis la branche 1.1.x un backend "système de fichier" (fsfs) est disponbile qui s'affranchi de ces problemes (corruption, compatibilité,...) de plus il apporte:
    * un gain de perf non négligable (jusqu'a facteur 4)
    * un gain de taille non négligable (taille de répository réduit jusqu'a facteur 3)

    Par contre, Subversion reste sur un modèle centralisé,


    Certe mais le projet Svk (basé sur les libs de Subversion) apporte un solution à ce problème.
    De plus on s'apporche de la release 1.0 (beta 2 en ce moment)

  • [^]Re: Suggestions

    Posté par Miguel Moquillon (Jabber id, page perso, ) le 21/04/2005 à 10:02. (lien). Évalué à 2.


    * 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,

    Pas tout à fait. Subversion a une architecture multi- protocolaire. Actuellement, deux protocoles sont supportés à plein :
    - propriétaire (svn) pour lequel il n'y a pas besoin d'un serveur HTTP (Apache, Caudium),
    - WebDAV pour lequel un serveur HTTP est nécessaire comme front-end à subversion (Apache, Caudium).
    Quant à son unique dépôt, je ne vois pas trop le désavantage. Dans la boite où je travaille, CVS est l'outil "standard" et il y a un dépôt pour chaque projet. Les sous-projets sont des modules.
    Ce qui est intéressant dans subversion, est son esprit "à la Unix" : tout est fichier, que ce soit une branche, le tronc commun, une marque, etc.

    • [^]Re: Suggestions

      Posté par Boa Treize (page perso, ) le 21/04/2005 à 15:14. (lien). Évalué à 2.

      Quant à son unique dépôt, je ne vois pas trop le désavantage. Dans la boite où je travaille, CVS est l'outil "standard" et il y a un dépôt pour chaque projet.

      Le désavantage, c'est qu'il faut ouvrir des droits pour chaque personne qui veut contribuer au projet, et ensuite gérer finement ses autorisations, ou lui faire confiance pour ne pas tout foutre en l'air. Un système distribué permet lui à tout un chacun de travailler dans son coin avec tous les bénéfices d'une gestion de version, et de venir contribuer quand il a quelque chose de correct (et la gestion de version n'est pas interrompue). Ceci dit, je comprends tout à fait qu'une boîte préfère Subversion.

      • [^]Re: Suggestions

        Posté par golum () le 21/04/2005 à 20:41. (lien). Évalué à 1.

        En même temps c'est ce qui en fait aussi sa simplicité.
        on a juste checkout/commit/merge
        et on a pas besoin de rajouter encore une couche de push/pull entre dépots et se coltiner des noms de dépots tarabiscotté ou des hashkey.

        La gestion centralisée permet de savoir qui travaille sur quoi et on mesure mieux l'avancement du projet (toutes les branches sont visibles sur le serveur et on a pas besoin de savoir où se trouve toutes les machines qui bossent sur le projet). C'est en ce sens que SVN correspond mieux au développement en société que pour des devs libres.
        Par contre avec un outils décentralisé on ne peut pas se passer d'outils de bug tracking parce que on se retrouve vite à ne plus savoir qui fait quoi. Avec des doublons on disperse pas mal d'énergie
        Je ne sais pas en revanche ce que vaut l'intégration entre outils de bug tracking et gestionnaires de version décentralisés.

        • [^]Re: Suggestions

          Posté par Boa Treize (page perso, ) le 21/04/2005 à 23:25. (lien). Évalué à 2.

          Sauf qu'on peut trivialement faire du centralisé quand on sait faire du décentralisé, l'inverse étant plus difficile.

          Le quotidien de l'utilisateur de base en décentralisé reste le commit et le merge, avec quelques push/pull sur des URI fixes (et généralement stockées dans la config) ; le quotidien de l'administrateur passe de surveillance de se qui se passe dans le dépôt (ou confiance aveugle) à série de push/pull avec URI variables effectivement. (Quoi que... Avec Darcs, ce quotidien peut aussi être : réception des mails, merge.) Notons à ce niveau que les URI de Darcs sont nettement plus sympa que celles d'Arch et de Monotone.

          Effectivement, un outil de tracking devient indispensable, même si l'open source se permet souvent d'être moins organisé et planifié que le commercial. À ce propos, il existe un patch pour utiliser Darcs au lieu de Subversion dans Trac.

          Trac :
          http://www.edgewall.com/trac/(...)

Hebergement

Posté par champi (page perso, ) le 21/04/2005 à 08:51. (lien). É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 Ph Husson () le 21/04/2005 à 10:27. (lien). É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 golum () le 21/04/2005 à 20:23. (lien). É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 baud123 (Jabber id, page perso, ) le 21/04/2005 à 11:26. (lien). É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 Boa Treize (page perso, ) le 21/04/2005 à 15:09. (lien). É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 Louis Nyffenegger (page perso, ) le 21/04/2005 à 16:39. (lien). É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 golum () le 21/04/2005 à 20:12. (lien). É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 mammique (Jabber id, page perso, ) le 21/04/2005 à 21:15. (lien). É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.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0871s (dont 0.007 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !