51 votes

Subversion vs CVS

J'ai utilisé un peu les deux SVN et CVS, mais je devrai en choisir un pour un nouveau projet que je vais lancer.

Quelqu'un qui a beaucoup utilisé les deux peut-il offrir des avantages et des inconvénients et juge ce qui est préférable? Les meilleures ressources d'apprentissage seraient également appréciées.

Ce sera pour un petit projet, juste un ou deux développeurs pour commencer.

68voto

Pistos Points 8997

J'ai utilisé à la fois. Il n'y a pas de comparaison, vous voulez svn. La seule raison d'utiliser CVS est parce que vous êtes de la saisie ou de la reprise d'un ancien système avec la direction qui ne veut pas changer le statu quo. Si vous commencez un nouveau projet, il est presque logique de l'impossibilité de prétendre que CVS est mieux que la Subversion.

Si vous avez autour de google, vous devriez trouver beaucoup de comparaisons, et les justifications relatives à l'utilisation de Subversion sur le CVS. Quelques-uns des avantages de Subversion sur CVS:

  • peut se déplacer ou renommer des fichiers ou des répertoires proprement
  • atomique s'engage
  • "bon marché" de la copie et la ramification
  • les commits sont des ensembles de modifications sur l'ensemble de l'arbre (et pas seulement des histoires sur des fichiers individuels)

Ayant dit tout cela, je vous recommande également d'explorer certains des distribué des Vcs comme Bazar, Mercurial et git. Personnellement, j'utilise git sur tous mes projets.

22voto

pte Points 237

La Subversion a d'importantes victoires sur CVS:

  1. bonne distance des options http/https/svn vs pserver
  2. atomique s'engage
  3. omniprésent, le support de l'outil
  4. renommer
  5. répertoire de gestion des versions

Cependant, il présente de sérieuses lacunes. La plus grande et de loin, est que les Branches et les Tags ne sont pas des citoyens à part entière dans le svn, ils sont juste des répertoires qui adhèrent à une convention. En plus de perdre certains des avantages de réel, de ramification et de marquage (mentionné dans d'autres commentaires) le plus gros problème qu'il crée est que si, il est très facile à visser.

La Subversion de l'utilisation de la convention plutôt que configuration signifie que vous devez penser à vos dépôts de la structure à l'avance et de s'assurer que tout le monde y adhère. D'autre, vous créez un monde de souffrance pour les générations futures, et encore moins tous les outils qui doivent grok votre repo.

La fusion et de la mise en miroir sont à peu près inexistantes (bien de l'aide pour) pré 1.5. 1.5 a pris des mesures pour répondre à ces deux, mais il y a encore de la place pour l'amélioration. La fusion dans la subversion est encore beaucoup plus difficile qu'il doit être.

SVN sur le CVS est presque une évidence. Cependant, vous m'en voudrais de ne pas considérer ce DVCS de l'offre (Git, Hg, Bzr) ou si votre budget le permet il y a des outils d'excellente réputation (Accurev, Forcément).

Subversion est probablement le bon choix, mais vous devez faire vos devoirs pour obtenir les meilleurs résultats. Commencer avec le Livre Rouge http://svnbook.red-bean.com/

14voto

JW. Points 17361

Bien que j'ai choisi de Subversion plus de CVS dans la plupart des cas, vous devez savoir ce que vous êtes absent de Subversion:

  • CVS voit les étiquettes et les branches comme des choses différentes, la Subversion n'est pas. Cela signifie que des outils de tiers, construit sur le haut de la Subversion (par exemple, IDEs de commande de source d'intégration) ont un travail plus difficile à connaître la différence. D'habitude vous avez à faire un peu de configuration spécial à lui dire où vos tags et branches, et vous devez vous assurer que vos utilisateurs de garder une certaine structure du système de fichiers.

  • Subversion ne peut pas regarder à un fichier et vous dire à quel point quelqu'un a créé une branche ou une étiquette. Des outils comme CVSGraph pouvez utiliser cette information pour dessiner un arbre d'un fichier de l'histoire. De le faire avec Subversion, vous devez à la recherche de toutes les branches/tags répertoires, et je n'ai pas vu tous les outils qui le font bien.

  • CVS a été autour de plus, et les outils tiers sont plus stables, dans mon expérience.

8voto

Gary Richardson Points 7371

Appelez-moi démodé, mais je préfère de beaucoup la ramification/marquage modèle sous CVS.

Dans les CVS, les branches et les étiquettes sont différentes des choses. Une étiquette est une étiquette de révision. Ils sont super utile pour des choses comme le marquage d'une PRODUCTION de tag pour les fichiers à synchroniser sur votre serveur web. Vous n'avez pas à fusionner pour mettre à jour la PRODUCTION de fichiers, il suffit de déplacer la balise.

Les Branches de vivre dans le même "espace de noms" le fichier principal-il est facile de traquer tous les mods d'un fichier particulier.

Dans le SVN il n'y a pas de telles choses comme une balise. Il y a seulement les branches. Si vous voulez des balises, vous devez créer une branche, et prétendre que c'est une étiquette. Les Branches sont essentiellement des copies de fichiers. La dernière fois que j'ai utilisé SVN pour branches/fusionne, vous avez eu à enregistrer la révision de la pré-ramifiée fichier si vous jamais souhaité l'intégrer ensemble (remarque, je ne suis pas un SVN expert, ce qui peut avoir changé).

Cela étant dit, je pense que SVN est mieux à tous autres égards, et vous ne devriez probablement pas commencer un nouveau projet avec CVS.

2voto

Greg Hewgill Points 356191

Vous allez obtenir beaucoup de réponses à cette, je le soupçonne. Ils pourraient même tous d'accord.

Entre ces deux choix, je crois qu'il n'est pas question que vous devez utiliser Subversion. Subversion a été construit comme un "mieux " CVS", et comme un résultat, personne ne soutient activement CVS plus longtemps. Subversion a la possibilité de renommer et déplacer des fichiers sans perte de l'histoire, prend en charge atomique s'engage, plus robuste référentiel format, a plus modernes méthodes d'accès, a un meilleur outil tiers de soutien, et la liste continue.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X