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.
J'ai utilisé les deux. Il n'y a pas de comparaison possible. vous voulez svn. La seule raison d'utiliser CVS est que vous entrez ou reprenez un système hérité avec un management qui ne veut pas changer le statu quo. Si vous démarrez un nouveau projet, il est pratiquement impossible de prétendre que CVS est meilleur que Subversion.
Si vous parcourez Google, vous devriez trouver beaucoup de comparaisons et de justifications pour utiliser Subversion sur CVS. Quelques avantages de Subversion par rapport à CVS:
- peut déplacer ou renommer des fichiers ou des répertoires proprement
- commet atomique
- copie et branchement "bon marché"
- les commits sont des changesets sur tout l'arbre (pas seulement des historiques sur des fichiers individuels)
Cela dit, je vous recommande d’explorer également certains VCS distribués, tels que Bazaar, Mercurial et git. J'utilise personnellement git sur tous mes projets.
Subversion a quelques victoires substantielles sur CVS:
- bonnes options à distance http/https/svn vs pserver
- commet atomique
- support d'outil omniprésent
- renommer
- versioning de répertoire
Cependant, il présente de graves lacunes. Le plus important, de loin, est que les branches et les balises ne sont pas des citoyens de première classe en svn, ce sont juste des répertoires qui adhèrent à une convention. En plus de perdre certains des avantages de la ramification et de l’étiquetage réels (mentionnés dans d’autres commentaires), le plus gros problème que cela crée est qu’il est très facile de tout gâcher.
L'utilisation de convention par Subversion plutôt que de configuration signifie que vous devez réfléchir à la structure de vos référentiels à l'avance et vous assurer que tout le monde y adhère. Sinon, vous créez un monde de souffrances pour les générations futures, sans parler des outils qui ont besoin de stocker votre rapport.
Les fusions et les reflets étaient presque inexistants (assistance pour) avant la 1.5. 1.5 a pris des mesures pour remédier à ces deux problèmes, mais des améliorations sont encore possibles. La fusion dans Subversion est toujours beaucoup plus difficile que nécessaire.
SVN over CVS est presque une évidence. Cependant, il serait négligent de ne pas au moins considérer ce que DVCS a à offrir (Git, Hg, Bzr) ou si votre budget le permet, il existe des outils commerciaux avec une excellente réputation (Accurev, Perforce).
Subversion est probablement le bon choix, mais vous devez faire vos devoirs pour obtenir les meilleurs résultats. Commencez avec le livre rouge http://svnbook.red-bean.com/
Bien que dans la plupart des cas, je choisirais Subversion plutôt que CVS, vous devriez savoir ce qui vous manque avec Subversion:
CVS considère les étiquettes et les branches comme des choses différentes; La subversion non. Cela signifie que les outils tiers construits sur Subversion (par exemple, les IDE avec intégration du contrôle de source) ont plus de difficulté à faire la différence. Vous devez généralement effectuer une configuration spéciale pour indiquer l'emplacement de vos balises et de vos branches, et vous devez vous assurer que vos utilisateurs respectent une certaine disposition du système de fichiers.
Subversion ne peut pas regarder un fichier et vous dire à quel moment quelqu'un en a créé une branche ou une étiquette. Des outils tels que CVSGraph peuvent utiliser ces informations pour dessiner une arborescence de l'historique d'un fichier. Pour faire cela avec Subversion, vous auriez besoin de chercher dans tous les répertoires de branches/balises, et je n'ai vu aucun outil le faire correctement.
CVS existe depuis plus longtemps et les outils tiers sont plus stables, selon mon expérience.
Appelez-moi à l'ancienne, mais j'ai de loin préféré le modèle de branchement/marquage sous CVS.
Dans CVS, les branches et les tags sont différents choses . Une balise est une étiquette pour une révision. Ils sont très utiles pour le marquage de balisesPRODUCTIONpour les fichiers à synchroniser avec votre serveur Web. Il n'est pas nécessaire de fusionner pour mettre à jour les fichiersPRODUCTION- vous déplacez simplement la balise.
Les branches vivent dans le même "espace de noms" que le fichier principal - il est facile de rechercher tous les mods d'un fichier particulier.
En SVN, il n’existe pas de tag. Il n'y a que des branches. Si vous voulez des balises, vous devez créer une branche et prétendre que c'est une balise. Les branches sont essentiellement des copies de fichiers. La dernière fois que j'ai utilisé SVN pour des branches/fusions, vous deviez enregistrer la révision du fichier pré-ramifié si vous espériez le fusionner (notez que je ne suis pas un expert SVN, donc cela a peut-être changé).
Cela étant dit, je pense que SVN est meilleur à tous les égards et vous ne devriez probablement pas démarrer un nouveau projet avec CVS.
Je suppose que vous obtiendrez beaucoup de réponses à cette question. Ils pourraient même tous être d'accord.
Entre ces deux choix, je pense qu’il ne fait aucun doute que vous devriez utiliser Subversion. Subversion a été construit comme un "meilleur CVS" et, par conséquent, plus personne ne maintient activement le CVS. Subversion a la capacité de renommer et de déplacer des fichiers sans perdre l’historique, prend en charge les commits atomiques, a un format de référentiel plus robuste, a des méthodes d’accès plus modernes, a un meilleur support des outils tiers, et la liste continue.
Subversion est comme un "meilleur CVS". Il gère bien les fichiers en mouvement ET les répertoires. Il prend en charge les branches, bien que ce soit inférieur aux VCS distribués.
Vous pouvez également envisager d’utiliser un VCS distribué tel que git, Bazaar ou Mercurial.
Edit: Voici un lien - vers une question similaire
Généralement Subversion .. Cependant, vous devez faire attention aux problèmes de ressources.
Lorsque je travaillais pour une entreprise de jeux vidéo, nous avions quelques répertoires contenant des centaines de fichiers minuscules et d’autres répertoires contenant quelques centaines de méga-fichiers. Lorsque nous sommes passés de CVS à Subversion, la vitesse de vérification du dépôt est passée de une heure à quatre ou cinq heures. La mise à jour a également été considérablement ralentie.
Ceci est certainement dû à l'utilisation de http ou de ssh pour transmettre des données de fichier, par rapport au pserver csv natif. Cependant, comme il est si facile de configurer svn sur ssh ou webdav, les gens ont tendance à ne pas penser à la surcharge de protocole. Vous pouvez cependant utiliser un protocole svn natif et cela devrait résoudre le problème. Nous n'avons pas testé cela dans mon ancienne société.
Un autre problème souvent ignoré est l’espace de stockage. Nous avons constaté que Subversion utilisait plusieurs fois plus de stockage localement que CVS. Je crois me souvenir qu’il stocke une copie locale des données du référentiel pour accélérer le traitement. Cela ne posera pas un problème énorme si vous ne stockez pas plusieurs giga-octets dans votre référentiel.
J'ai utilisé Subversion pendant 3,5 ans et maintenant je suis passé chez une autre société qui utilise CVS pour le contrôle de source. Au début, il n'y a pas beaucoup de différences entre les deux, mais au moment de fusionner les opérations (ce qui est la principale préoccupation de la plupart de mes préoccupations), je pourrais dire que CVS a mieux travaillé. Les concepts de branches/tags dans SVN prêtent à confusion mais sont très clairs dans CVS. De plus, la fusion (dans mon cas, l'intégration d'une branche) est beaucoup plus facile dans CVS que dans SVN . La faiblesse de CVS est jusqu'à présent dans mon idée que le commit atomique. sinon, ce serait un bon choix.