Question

Mon entreprise utilise CVS comme standard de facto pour le contrôle des sources.Cependant, j'ai entendu beaucoup de gens dire que SVN est meilleur.

Je sais que SVN est plus récent, mais à part ça, je ne connais pas ses avantages.

Ce que je recherche, c'est une bonne et succincte comparaison des deux systèmes, notant les avantages ou les inconvénients de chacun dans un environnement de développement Java/Eclipse.

Était-ce utile?

La solution

CVS ne suit les modifications que fichier par fichier, tandis que SVN suit l'ensemble d'un commit comme une nouvelle révision, ce qui signifie qu'il est plus facile de suivre l'historique de votre projet.Ajoutez le fait que tous les logiciels de contrôle de code source modernes utilisent le concept de révision, il est donc beaucoup plus facile de migrer depuis SVN que depuis CVS.

Il y a aussi le problème de la validation atomique.Bien que je ne l'ai rencontré qu'une seule fois, il est possible que 2 personnes s'engageant ensemble dans CVS puissent entrer en conflit, perdant certaines données et mettant votre client dans un état incohérent.Lorsqu’ils sont détectés tôt, ces problèmes ne sont pas majeurs car vos données sont toujours là quelque part, mais cela peut être pénible dans un environnement stressant.

Et enfin, peu d’outils sont développés autour de CVS.Alors que les nouveaux et brillants nouveaux outils comme Git ou Mercurial manquent définitivement d'outils, SVN dispose d'une base d'applications assez importante sur n'importe quel système.

MODIFIER 2015:Sérieusement, cette réponse date de 7 ans maintenant.Oubliez SVN, allez utiliser Git comme tout le monde !

Autres conseils

Une des nombreuses comparaisons :

http://wiki.scummvm.org/index.php/CVS_vs_SVN

Maintenant, c'est très spécifique à ce projet, mais beaucoup de choses s'appliquent en général.

Subversion Pro :

  • Prise en charge des renommages/déplacements versionnés (impossible avec CVS) :Fingolfin, Ender
  • Prend en charge les répertoires de manière native :Il est possible de les supprimer, et ils sont versionnés :Fingolfin, Ender
  • Les propriétés des fichiers sont versionnées ;plus d'enfer de "bit exécutable":Fingolfin
  • Le numéro de révision global facilite grandement la gestion des versions et les tests de régression :Ender, Fingolfin
  • Engagements atomiques :Fingolfin
  • Branchement et balisage intuitifs (basés sur un répertoire) :Fingolfin
  • Scripts de hook plus simples (pre/post commit, etc.) :SumthinWicked (je l'utilise pour Doxygen après les commits)
  • Empêche la validation accidentelle de fichiers en conflit :Cheval salé, Fingolfin
  • Prise en charge de la commande 'diff' personnalisée :Fingolfin
  • Des différences hors ligne, et elles sont instantanées :sev

SVN présente 3 avantages principaux par rapport à CVS

  • c'est plus rapide
  • prend en charge la gestion des versions des fichiers binaires
  • et ajoute un commit transactionnel (tout ou rien)

Le livre Subversion a une annexe qui détaille les différences importantes par rapport à CVS, ce qui peut vous aider à prendre votre décision.Les deux approches sont plus ou moins la même idée, mais SVN a été spécialement conçu pour corriger des défauts de longue date dans CVS donc, en théorie du moins, SVN sera toujours le meilleur choix.

J'appuie la suggestion d'Eridius concernant Git, mais je l'étendrais aux autres DRCS (Distributed Revision Control System) tels que Mercuriel et bazar.

Ces produits sont assez récents et le niveau d'outillage et d'intégration avec eux semble faible pour le moment (d'après mes recherches initiales).Je dirais qu'ils étaient les mieux adaptés aux développeurs de puissance (et ici ;-)).

D'un autre côté, quoi n'a pas CVS le fait-il actuellement pour vous ?D'après votre question initiale, vous n'en avez pas vraiment, "CVS est nul, que pourrais-je utiliser à la place ?"

Vous devez peser les coûts de toute migration potentielle par rapport aux avantages.Pour un projet existant, je pense que ce serait difficile à justifier.

Une chose à ne pas négliger est l’écosystème.Je travaillais dans une boutique CVSNT et je trouvais de plus en plus d'outils open source prenant en charge SubVersion par défaut.

d'ailleurs:CVSNT prend en charge les commits atomiques

En tant que personne en train de basculer entre CVS et SVN (au départ, nous avons changé tous nos projets avec cvs2svn, puis avons décidé que nous effectuerions la transition en utilisant uniquement svn sur de nouveaux projets), voici quelques-uns des problèmes que nous avons rencontrés.

  • La fusion et le branchement sont très différents, et si vous créez et fusionnez fréquemment, à moins que SVN 1.5 ne soit exécuté sur votre serveur, vous devez savoir quand vous avez créé un branchement (ce n'est pas très clair dans les boîtes de dialogue Tortoise SVN).Michael dit que le branchement et la fusion sont intuitifs, je dirais qu'après avoir utilisé CVS pendant 10 ans, ce n'est pas le cas.
  • Si vous exécutez le serveur SVN sous Linux, il peut être difficile de faire passer votre SA à svn 1.5, comme installation par défaut 1.4.x.
  • La fusion des conflits n'est pas aussi facile ou aussi claire (du moins pour moi et mes collègues) dans TortoiseSVN comme dans TortoiseCVS.L'approche à trois volets prend un certain temps pour s'y habituer et WinMerge (mon outil de fusion préféré) n'effectue pas de fusion à trois volets.
  • Méfiez-vous:la plupart des didacticiels en ligne et des articles de magazines que j'ai lus ne comportent évidemment pas de branchements ni de fusions, vous devez configurer votre référentiel principal comme suit : https://svn.yoursvnserver.com/repos/YourProject/Trunk et des succursales sur https://svn.yoursvnserver.com/repos/YourProject/Branches/BranchX .Vous pouvez nettoyer si vous démarrez vos dépôts au mauvais endroit, mais cela prête à confusion.

Tu devrais jeter un oeil à Git au lieu de SVN.C'est un DVCS ultra-rapide et très puissant.Ce n'est pas aussi convivial que SVN, mais il s'améliore à cet égard, et ce n'est pas le cas. que difficile à apprendre.

CVS (Concurrent Versions System) et SVN (SubVersioN) sont deux systèmes de fichiers de contrôle de version couramment utilisés par les équipes qui collaborent sur un seul projet.Ces systèmes permettent aux collaborateurs de suivre les modifications apportées et de savoir qui développe quoi et si une branche doit être appliquée au tronc principal ou non.CVS est le plus ancien des deux et constitue l'outil de collaboration standard pour de nombreuses personnes.SVN est beaucoup plus récent et introduit de nombreuses améliorations pour répondre aux demandes de la plupart des gens.

vous pouvez également choisir de migrer uniquement le dernier code de CVS vers SVN et de geler votre dépôt CVS actuel.cela facilitera la migration et vous pourrez également créer vos anciennes versions dans l'ancien dépôt CVS.

Eh bien, il y a quelques choses qui, à mon avis, rendent svn génial.

  1. La combinaison de creusets SVN-Altassian est une méthode bien supérieure d'examen et de contrôle de qualité.
  2. Meilleure gestion des conflits et des fusions
  3. C'est évidemment plus rapide pour effectuer des paiements, effectuer des commits, etc.
  4. Le problème de la validation atomique - Il est possible que 2 personnes s'engageant ensemble dans CVS puissent entrer en conflit, perdant des données et mettant votre base de code dans un état incohérent.

La migration peut facilement être effectuée en quelques heures en utilisant cvs2svn.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top