Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Gestion de projets ? Choisir CVS ou Subversion ?
Bonjour,
J'ai toujours travaillé avec CVS mais je me pose la question de passer à SUBVERSION.
Quels sont les avantages et inconvénients de l'un par rapport à l'autre ?
Quelque articles CVS
CVS sur le Dico
Quelque articles Subversion
Merci d'avance
Cordialement,
elitost(Eric Reboisson)
SpringSource Certified Spring Professional
Certifié SCWCD J2EE 5.0
Certifié SCJP J2SE 5.0
Certifié ITIL Foundation
Responsable : FAQ Maven 2 , FAQ SCM
Autres : Site web Developpez , Mon site personnel , Mon CV
Twitter : Suivez moi sur Twitter
Voici un article qui peut t'éclairer sur le choix d'un outil de gestion de version : Version Control System Comparison
La personne qui a écrit cet article semble avoir un peu privilégié Subversion. J'ai pu lire des 'Yes' Subversion peut faire ca grace au module ou à l'add on xxx. Dans ce cas beaucoup de 'No' d'autres controleurs de sources peuvent aussi devenir des 'Yes'.Envoyé par Yann21
Avec des 'si' on met Paris en bouteille.
Ceci dit je vanais lire ce message pour autre chose. J'ai moi aussi un question concernant CVS et Subversion. L'un semble fonctionner avec un repository composé de plusieurs modules. L'autre avec plusieurs repositories. Est t'il possible de créer des interdépendance entre ces modules/repositories comme le permet Visual Source Safe ? Voyez vous ce que je veux dire ?
Pour démarrer, cela n'a pas beaucoup d'importance.
SVN est cependant plus complet et plus "juste" (problématique du commit atomique)
Si tu veux investir un peu dans ce domaine pars donc sur SVN
Subversion a aussi l'avantage d'être dispo par protocole http
Va pour subversion. Mais comment procède-t-on ? Existe-t-il un tutoriel (j'ai cherché sur le net et rien trouvé)
Tout d'abord, il te faut un serveur Subversion. Soit tu crées un projet libre -> sourceforge, gna, ... Sois tu crées un serveur chez toi avec Apache, webdav et dav-svn - sous Debian, c'est un apt-get install avec les bons paquets, je peux te les chercher si besoin est -
.
Ensuite du côté client, si tu es sous Linux, installe un paquet subversion, sous Windows, installes TortoiseSVN, ça marche du tonnerre.
Ce n'est peut-être pas ce que l'on peut appeller un tutoriel, mais le «Subversion Book»
http://svnbook.red-bean.com/ est excellent. Je débute également avec subsersion, je n'ai aucune expérience d'un tel outil et pourtant je n'ai pas vraiment eu de difficulté à l'installer et l'utiliser. Et en cas de problème il y a les listes de diffusions (http://subversion.tigris.org/servlet...ailingListList) et un canal irc #svn sur freenode très fréquenté.
Perso, ce qui est sympa je trouve avec svn est la facilité avec laquelle on peut manipuler les fichiers/repertoires sans perdre l'historique.
--
SaintAmand
un autre outil
hello
un autre outil, basé sur les principes de continuus, est aussi dispo sur http://www.goudniouz.com
ca integre à la fois une gestion des sources, et un bug tracker. Tout est propriétaire java, sauf la base de donnée, qui vient de chez Apache.
c'est basé sur un principe de tâche de développement, nettement plus puissant que ce que propose svn.
SVN depasse CVS sur pas mal de point apparement
Dans le style, il y a aussi et surtout TRAChello
un autre outil, basé sur les principes de continuus, est aussi dispo sur http://www.goudniouz.com
c'est un outil gratuit qu'un groupe de collègues a réalisé ces derniers mois, après des semaines d'évaluation sur les outils du marché.
ca integre à la fois une gestion des sources, et un bug tracker. Tout est propriétaire java, sauf la base de donnée, qui vient de chez Apache.
c'est basé sur un principe de tâche de développement, nettement plus puissant que ce que propose svn. Ca vient de sortir, il y a encore du boulot, mais ça a l'air assez prometteur !!
jetez un oeil, ça vaut le coup je crois
Trac..
TRAC, en effet, propose une interface vers subversion.
l'un des défauts que je reproche à svn, c'est le fait de travailler sur des sources sans que personne ne puisse le savoir. Et le conflit n'apparaît qu'au commit, bien trop tard. Tous les enseignant du cycle en V s'accordent à dire que plus un problème (en l'occurence, le merge) est découvert tard, plus il coute cher, le bon sens non ?
Un outil qui, à l'instar de synergy, propose à la fois de visualiser les conflits avant qu'ils n'existent réellement, associe les objets modifiés avec une tâche de développement, les deux étant commités de façon transactionnel... tout ça sans empêcher de travailler en parallèle sur des fichiers quand c'est nécessaire, c'est quand même pratique.
Le fait est que synergy, du fait de son prix très élevé, n'est pas à la portée de petites sociétés. Pourtant, l'approche que cet outil propose est beaucoup plus productive que celle de svn. Tout le monde est très habitué à svn, et pourtant, de mon point de vue au moins, mais aussi de celui de tous les habitués de synergy, svn relève de la préhistoire en face de synergy.
c'est tout une culture à changer, un vrai défi, et pourtant, le gain est bien réel.
Alors d'accord, svn, c'est gratuit.. mais justement, avs (de goudniouz) est basé sur les concepts de synergy et gratuit lui aussi.
du reste, l'ergonomie de TRAC...
Tu prends pour exemple les cycles en V, alors qu'eux s'en foutent complètement de la retard à la découverte de bugs. Si on prend un vrai process qui se préoccupe de l'intégration et de la découverte des bugs très tôt, regarde du côté des process agiles où l'intégration se fait limite au jour le jour et dans ce cas, aucun problème avec SVN. Le fait de locker, même virtuellement, le fichier ne changera pas le problème : il faudra intégrer les différences, avec ta méthode qui te le dira dès le départ et celle d'SVN. Avec la différence que pour SVN tout le monde est logé à la même enseigne. Quid du premier développeur qui a récupéré le fichier ? On va dire comment qu'il est en train de modifier un fichier et répercuter le souci sur le repository sans conexion ?
je ne suis pas sûr qu'on parle de la même chose
avec svn, si tu commences des modifs, personne ne le sait, sauf si tu lock le fichier, auquel cas personne ne pourra commiter des modifs pendant tout ce temps.
résultat des courses, deux personnes peuvent très bien faire des modifs sur le même fichier, ils ne s'en rendront compte que lorsque le deuxième commit, alors que s'ils avaient su au départ qu'ils étaient en conflits, l'un d'eux aurait peut être attendu que l'autre finisse. Au mieux, le merge se passe bien. Sinon, ils peuvent très bien avoir fait plus ou moins les mêmes choses, et au pire, ils ont fait du boulot contradictoire. De toutes façon, c'est potentiellement beaucoup de temps perdu.
pour avoir travailler avec les deux, synergy et svn, je sais de quoi je parle !
avec synergy comme avs, lorsqu'une personne veut modifier un fichier, il fait un check-out: une nouvelle version du fichier est créée avant même toute modif. Ensuite, si une autre veut aussi faire un check-out, l'outil avertit qu'il va créer une version parallèle: le conflit est detecté avant que les développements conflictuels soient faits. Après dialogue, les developpeurs peuvent choisir la meilleure stratégie: créer une version parallèle, ou attendre.
Au moins, ils sont sûrs de se synchroniser avant et non pas après le boulot, c'est ça que je voulais dire, au sujet du cycle en V et de l'anticipation qui fait gagner du temps, et donc de l'argent.
précision
avec synergy comme avs, un check-out met la nouvelle version du fichier dans un état "working" qui empêche les autres utilisateurs que le propriétaire de cette version, de le récupérer.
c'est uniquement au check-in (l'équivalent du commit) que le fichier repasse dans l'état "released", accessible à tous.
en outre, le fait d'utiliser un container (la tâche de développement) fait que tu peux travailler sur plusieurs tâches en même temps: tu sais au moment de faire le check-out, ce que tu vas faire sur ton fichier, donc tu l'associes à la bonne tâche au moment de l'extraire.
suppose que fasses la même chose avec svn: tu travailles sur plein de fichiers en même temps, pour corriger, mettons, deux bugs différents. Pour bien faire, il faudrait faire deux commits différents, chacun incluant les fichiers modifiés pour les deux bugs différents. Comment, après tout le travail, te souviens tu de quels fichiers a été modifié pour quel bug ? tu as toutes les chances de te tromper..
enfin, au niveau du build management, avec svn, si tu veux exclure les modifs faites pour la correction d'un bug, supposons pas assez testé au moment de livrer, comment fais tu pour récupérer les bonnes versions des fichiers ??
synergy et avs utilisent un concept de template, dans lequel tu précises la liste des tâches (et donc les versions de fichier associées) que tu souhaites.
je mets au défi les utilisateurs de svn de traiter ce problème !!
Imaginons, j'update mon repository à un moment, puis je rentre chez moi et je commence à modifier certains fichiers. Je fais comment ? Je précise au départ que je peux potentiellement modifier tous les fichiers ?
Pour retrouver une version sans certains bugs fix, suffit d'aller à la branche adéquate sous svn.
si tu rentres chez toi, je comprends que tu n'es plus en relation avec l'outil de gestion de conf, n'est ce pas ? dans ce cas, en effet tu es obligé de travailler "a la svn", si je puis dire, mais c'est une pratique peu recommandée par synergy, justement parce que personne ne peut savoir ce que tu fais. Néanmoins, tu as quand même la possibilité de mettre à jour la repository avec tes modifs, a posteriori, via un synch. Le risque de cette pratique, c'est justement qu'entre temps, les autres peuvent avoir pris la main sur les fichiers que tu as modifié, et là encore, tu seras obligé de faire un merge que personne n'avait prévu au départ.
Sur synergy, effectivement, tu peux faire des check-out et rentrer chez toi avec les fichiers "working". Non seulement les autres vois que tu as pris la main sur les fichiers, mais en plus, même en gardant les fichiers dans cet état, tu peux sauvegarder le contenu de tes fichiers "working" sans faire de check-in. Résultat, d'une part tu fais une sorte de backup en cours de travail, mais en plus, les autres peuvent (a confirmer sur synergy, bientôt possible avec avs) voir les modifs en cours, même s'ils ne peuvent pas faire de check-out sur la version "working" (ils sont obligés de faire une version parallèle de l'objet s'ils ont besoin de le prendre)
je suppose que ça implique de faire une branche par commit, je me trompe ? supposons que tu commit un certain nombre de modifs, et qu'ensuite un autre en commit d'autres, sans tag ni branche, comment fais tu pour récupérer les modif du second sans celle du premier commit ?
précision
précision importante de vocabulaire: sous synergy, ce qu'on appelle repository, ce sont les sources serveur, contrairement à toi, apparemment ce que tu appelles repository, c'est ton espace local, appelé workarea sous synergy.
ça peut aider à comprendre mon post précédent
:d
tu es dur à convaincre, mais j'y arriverai
Le repository, c'est le serveur pour SVN, comme pour CVS
Pour chaque commit, il y a une branche dans SVN, c'est ce qui m'étonne dans tes dires, tu as l'air d'avoir travaillé avec lui, mais tu ne connais pas ses caractéristiques.
Il est vrai qu'avoir un indicateur pour un éventuel merge peut être intéressant quand on travaille pendant des jours sans commiter, mais dans le cas de commits journaliers, c'est moins gênant.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager