Forum Programmation.autre A la recherche du meilleur outil ...

Posté par  .
Étiquettes : aucune
0
17
sept.
2009
Bonjour.

A ce jour je suis à la recherche d'un outil pour gérer des sources (scripts shell ainsi que deux ou trois petits projets en Ruby/Rails. Je souhaiterais également y stocker les configurations de mes quelques machines ici). Je connais un peu subversion pour l'avoir utilisé (j'ai même acheté à l'époque un bouquin o reilly), cependant il semble qu'à ce jour il y a "mieux" que subversion, quand on se trouve dans certains cas d'utiisation.

A ce jour, les deux grandes familles de gestionnaires de version sont : client-serveur et distribué. Quel est l'intérêt d'un gestionnaire de version distribué par rapport à un gestionnaireclient-serveur ? Qu'est-ce que ça change dans la façon de travailler ?

Maintenant parlons des gestionnaires en tant que tels : bazaar, arch, DaRCS, git, mercurial, et svk. quels sont leurs points forts/points faibles? Avez-vous migré vde l'un vers l'autre ? Pourquoi ? Qu'est-ce que ça vous a apporté (avantagesnconvénients) ? Si je pars sur une solution (SVN en client-serveur par exemple), pourrai-je migrer facilement de l'un a l'autre ?

Merci pour votre retour.

  • # avis d'un amateur qui lit mais pratique peu

    Posté par  . Évalué à 4.

    distribué/client-serveur :
    comme tout les systemes de ce genre
    client-serveur : si ton serveur tombe, tu perd tout
    distribué : si ton depot tombe, tu peux aller taper sur un autre depot

    evidemment si tu es tout seul avec un serveur, le distribué devient du client/serveur

    facon de travailler ?
    c'est pareil, dans les 2 cas tu peux exporter tes branches de dev/trunk/stable etc
    tu peux envoyer du code, commenter les versions, recuperer la version n-X...

    les outils, j'ai utilisé un peu svn
    facile à configurer (un dossier = un developpement, une branche)
    à utiliser, ca passe avec ssh en souscouche, donc tres pratique dans certains cas de config reseau

    git semble etre pas mal (outil créé par Linus et utilisé dans le developpement du noyau)

    migration, aucune idée jamais fait.

    • [^] # Re: avis d'un amateur qui lit mais pratique peu

      Posté par  . Évalué à 2.

      distribué/client-serveur :
      comme tout les systemes de ce genre
      client-serveur : si ton serveur tombe, tu perd tout
      distribué : si ton depot tombe, tu peux aller taper sur un autre depot


      Est-ce le seul avantage ? En fait pour le moment je serai seul à travailler sur la plupart des projets sauf deux ou trois sur lesquels nous serions un peu plus (moins de 5 parsonnes différentes/projet).

  • # plutôt distribué

    Posté par  . Évalué à 2.

    Ce n'est pas le cas aujourd'hui, mais si j'avais du code à diffuser, ça serait via un gestionnaire de conf distribué sans hésitation.

    Sans connaissance particulière de gestionnaire de conf, je serais aussi parti sur du distribué.

    J'utilise cvs chez moi, mais vraiment pour une seule raison (je veux dire, en dehors du fait que ça marche) : c'est un outil que je connais déjà très bien.

    du coup, si tu n'es pas plus à l'aise que ça avec svn, je te conseillerais plutôt de taper sur du distribué. Quant à savoir lequel .. heu ... joker ?

    (pas d'expérience sur migration de svn vers autre chose non plus)

    • [^] # Re: plutôt distribué

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

      Tout dépend de la politique... SVN est centralisé est cela peut être bien pour centraliser les choses. Par exemple, dans un laboratoire de recherche, svn permet d'avoir une idée des codes développés et d'en avoir une version. Trop souvent, on ne sais plus bien ce que l'on a et il arrive que l'on perde ainsi les sources !

      Sinon, SVN a aussi un très bon client sous Windows (TortoiseSVN). Si des personnes doivent travailler sous Windows, il faut contrôler la qualité du client sur cet OS.

      • [^] # Re: plutôt distribué

        Posté par  . Évalué à 2.

        L'outil technique n'est qu'un élément de la gestion de conf. Ce que tu décris, ça me paraît plutôt être un problème de process. Utiliser un gestionnaire de conf centralisé est un moyen de pallier le problème que vous rencontrez, mais ça serait sûrement possible d'aboutir au même résultat avec d'autres outils.

        • [^] # Re: plutôt distribué

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

          Je suis d'accord et je n'ai pas dis que c'était la meilleure solution. Il est clair que dans les laboratoires de recherche, c'est très dé-centralisé comme mode de fonctionnement. Avoir un outil qui permet à l'utilisateur non informaticien de centraliser les choses est pas mal.

          Je sais que dans certain cas, SVN connait des limites (sur le merge de branche) mais des outils comme git sont trop complexe pour des utilisateurs lambda qui ne connaissent rien à la gestion de projet en informatique.

          Donc SVN, couplé à TRAC est un bon moyen d'introduire ce genre de problématique et du coup de former les utilisateurs a ce genre de technique. Lorsque nous avons fait ce choix la il y a deux ans, il n'y avait pas bien d'autres solutions multi plateforme ayant des clients aussi aboutis (TortoiseSVN pour Windows).

  • # hgbook en français

    Posté par  . Évalué à 2.

    Nous sommes quelques uns à traduire en ce moment le bouquin de mercurial, les premiers chapitres sont fait, tu peux aller voir http://belaran.eu/hgbook-fr-SNAPSHOT/read/

    Le premier chapitre parle justement du choix d'un gestionnaire de sources

  • # svn, valeure sûre

    Posté par  . Évalué à 2.

    je suis un peu dans ton cas d'usage: versioning de projet perso, de configuration système.
    J'utilise SVN pour ça. J'en faisait un usage intensif sur des projet important - au sens du nombre d'intervenants - en entreprise.
    Un gestionnaire de version distribué est très bien quand tu as beaucoup d'équipes qui travaille sur un très gros projet fait de nombreux composants.
    En SVN, les révisions sont de simples fichiers, donc extrêmement simple à sauvegarder.
    De plus, SVN peut être déployé en mode client serveur mais aussi (et surtout pour ton cas) en mode fichier, il n'y a alors pas besoin de démon, juste la ligne de commande svn.

Suivre le flux des commentaires

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