Je viens de trouver un projet open source qui utilise toujours CVS. Je me demandais s'il y avait toujours des raisons de préférer les CV sur SVN ou Git de nos jours. (Je ne compte pas être trop paresseux pour migrer comme une réponse! ;-))
Les CV ont-ils quelque chose que les deux autres manquent? Dis, Support pour $ OS ou $ FANCY_TOOL?
in " Quels sont les avantages de l'utilisation de SVN sur les CVS ? "Il y a des réponses élaborées pourquoi ne pas utiliser CVS. Mais je veux demander l'inverse. Les CVS ne peuvent pas être tous mauvais. Ou est-ce?
4 Réponses :
La seule chose que j'ai rencontrée dans mon usage limitée de CVS est que les CVS traitent des succursales et des étiquettes aussi différentes et les traitent également comme ce qu'ils sont et non comme des dossiers que SVN le fait. Il existe des commandes spécifiques pour celles-ci et elles sont traitées comme des citoyens de première classe du système de contrôle de la version. Comment créez-vous une succursale dans SVN? Mais définitivement, il n'ya aucune raison d'utiliser des CVS maintenant-un jours, à part des raisons héritées. Beaucoup disent que SVN était construite pour être un meilleur CV et dans presque tous les aspects, SVN est meilleur et est largement utilisé. Copie SVN . Étiqueter? même. Quelle est la différence? Rien vraiment, sauf comment vous les traitez. Bien que l'on puisse dire que le modèle de SVN conduit à la simplicité, il provoque divers outils pour les mal comprendre et ne pas obtenir le contexte des dossiers. Si vous voyez Git, il est similaire aux CVS de cette manière.
Des déclarations à travers la carte comme celle-ci sont vraiment gênantes. La réponse de Keith Thompson est correcte et de côté des raisons héritées, je trouve toujours des CVS utiles et svn une pire option de nos jours. Je préférerais beaucoup utiliser des CV ou un certain nombre de nouveaux DVCs sur SVN. Il a créé toutes sortes de problèmes au nom de la "fixation" CVS et, en tant qu'utilisateur lourd des deux outils, je n'ai jamais choisi de soumettre à l'ensemble de problèmes SVN créés pour elle-même (c'est-à-dire le stockage du stockage complet de l'ensemble du référentiel pour le marquage et plus, ce que je ne vais pas décrire en détail ici).
@kbulgrien Vous réalisez que vous réalisez qu'une étiquette SVN n'est pas en fait un duplicata, non? Il semble que l'utilisateur soit un, mais dans les coulisses, il vient de stocker comme un lien sympathique.
Je pourrais accorder que SVN ait peut-être changé puisqu'il a perdu mon vote, mais je suis bien conscient de la consommation de stockage plus poussée lors de l'utilisation, et cela a entraîné une duplication massive dans divers cas. Je ne vais pas entrer dans un argument de détails. Ne laissez pas oublier qu'il y a à la fois un côté client et un côté serveur à considérer. Je note que vous êtes en désaccord et je me contente de le laisser à cela.
@ Kbulgrien La copie légère est une caractéristique essentielle de SVN au moins depuis que j'ai commencé à l'utiliser vers 2005 (et probablement avant cela). Si vous critiquez quelque chose, assurez-vous que vos critiques sont exactes. (Je suis depuis passé en git, bien sûr, je n'ai donc pas utilisé SVN récemment.)
J'utilise toujours des CV pour certaines de mes affaires personnelles.
Contrairement à GIT, vous ne pouvez facilement consulter qu'un sous-ensemble du référentiel.
et CVS attribue des numéros de version séquentielle (1.1, 1.2, 1.3, ...) à chaque fichier. En GIT, les numéros de version sont des checks hexadécimaux de 40 caractères. Dans SVN, les numéros de révision sont séquentiels sur tout le référentiel; Un nombre donné s'applique à l'ensemble du référentiel.
et CVS vous permet de développer des numéros de version dans chaque fichier lors de la vérification de la vérification, ce qui facilite l'identification de la version à laquelle un fichier est sans référence au référentiel.
Donc, je trouve des CVS (et parfois même les CR) lorsque le référentiel est une collection de fichiers en grande partie non liées, et je suis plus intéressé par le suivi des modifications des fichiers individuels, mais les révisions du référentiel dans son ensemble ne sont pas particulièrement significatives. .
(ce ne sera pas le cas si le référentiel contient des fichiers source utilisés pour créer un seul programme ou une bibliothèque; dans ce cas, vous voulez une histoire cohérente pour le projet dans son ensemble.)
Enfin, CVS stocke l'historique de chaque fichier dans un seul fichier (avec le même format utilisé par RCS) avec un format relativement simple. Au moins une fois, j'ai dû reconstruire manuellement un fichier CVS enregistré qui était devenu corrompu. Je ne sais pas comment j'aurais pu faire cela avec SVN ou Git.
Dans les années depuis que j'ai écrit cela, j'ai presque entièrement abandonné les CVS en faveur de Git.
Vous devez comprendre que la subversion a été écrite pour remplacer directement les CV et les développeurs de problèmes avec CVS. Subversion a été écrit, de sorte que les utilisateurs de CVS puissent facilement passer de CVS à Subversion car ils utilisent le même flux de travail et de nombreux concepts similaires.
Ceci est en quelque sorte comme demander comment MS-DOS supérieure à Windows en tant que système d'exploitation. Je pourrais proposer des fausses raisons (" bien ... ... euh ... MS-DOS a besoin de moins de mémoire. "). Mais, à la fin, Windows a été écrit pour prendre soin des courtes allées de MS-DOS.
Certaines raisons pour lesquelles CVS est préférable à Subversion, ne vous tenez tout simplement pas une fois que vous comprenez le raisonnement:
CVS était une grande amélioration sur les RCS. Dans CVS, vous n'avez pas eu à verrouiller un fichier avant de le changer. Dans CVS, vous pouvez commander des sous-arbres entiers sans écrire une sorte d'extrémité avant du système. RCS a été développé à la version des fichiers individuels. Les CVS ont versé votre référentiel entier comme un seul projet.
RCS elle-même était une amélioration de la SCCS. Le format de référentiel RCS était plus facile à comprendre. Le mot clé expansion a fonctionné mieux et était moins cryptique. Vous pouvez avoir des branches de succursales pendant que SCCS vous a laissé uniquement un seul niveau de branche. RCS avait le concept intégré de tags tandis que SCCS vous avait besoin de suivre les étiquettes vous-même.
et CSCS était bien meilleur que de ne pas utiliser de référentiel source du tout.
La vérité est que les CVS ont été remplacés par Subversion, puisque Subversion est sorti de plus d'une décennie, tous les travaux sur CVS ont un halt. Je ne pense même pas que les bugs ne soient plus réparés sur CVS.
, V , les succursales et les balises ont été aliasés à des révisions particulières au début du fichier. En fait, vous avez utilisé la même commande: cvs tag pour créer une branche ou une balise. C'est l'une des raisons pour lesquelles Subversion n'a pas fait de distinction entre les deux concepts. Cependant, en traitant des branches et des étiquettes, Subversion vous a donné un moyen de suivre l'histoire d'une succursale ou d'une balise. Qui l'a créé et quand? Quelle révision était-elle basée sur? A-t-il été changé? Subversion vous donne également un moyen facile de voir toutes les balises ou les branches de votre référentiel. Dans CVS, vous devez passer par chaque fichier.
La fixation des bugs sur les CVS briserait probablement le flux de travail pour les personnes qui l'utilisent toujours, qui sont très susceptibles de s'appuyer sur eux étant présents.
À partir d'un utilisateur de CV et de Subversion très expérimenté, Subversion a principalement échangé un ensemble de problèmes avec CVS à un autre ensemble utilisé avec des projets complexes. SVN "Correction" certaines choses et introduit des complexités et d'autres problèmes. À l'approche sérieusement de l'utilisation de Subversion par rapport à la Subversion contre CVS était un gros "non" pour moi. Je préférerais que les CV ou tout autre DVC sur subversion, mais à la fin, la réponse qui indique que CVS est toujours viable est une réponse légitime. CVS 12.x est suffisamment stable que les distributions l'envoient, et il fait même que la version s'engage (en plus de la version de fichier par fichier).
@kbulgrien Qu'avez-vous spécifiquement pensez-vous que CVS fait mieux que SVN? Ayant utilisé à la fois raisonnablement largement, je ne peux pas penser à une seule chose que CVS fait mieux, et le fait que CVS ne stocke pas une version pour le projet dans son ensemble (sauf si vous ne créez spécifiquement un Tag) Le rend fondamentalement inapproprié pour le développement moderne, car des projets à un seul fichier sont rares ces jours-ci. (Bien sûr, ces jours-ci, les DVCS sont la voie à suivre.)
Une seule personne aime accepter cela, il y a encore des cas de niche où les CVS peuvent être utiles dans un âge moderne (bien que cela ne soit pas censé défendre l'utilisation de CVS sur un VC plus moderne.) C'est plutôt hautain d'assumer une sait utiliser des cas pour toutes les personnes partout. Vraiment, il n'y a pas de mérite en discutant cela.
@kbulgrien Great, donc si j'ignore un cas d'utilisation que CVS sert mieux que SVN, alors Dites ce que cet étui d'utilisation est , ne m'accuse pas simplement d'être "hautain". J'aimerais vraiment savoir quel serait un tel cas d'utilisation.
CVS, git et subversion ont des conceptions de flux de travail différentes. Il est inexact et trompeur de dire (Git / Subversion a été conçu pour résoudre les problèmes de CVS). Au lieu de cela, Subversion a été écrite, car une personne voulait un flux de travail différent que les CVS / RCS fonctionne le mieux avec. Et puis git a été écrit parce que quelqu'un voulait encore un autre flux de travail différent.
Superficiellement, Subversion et CVS sont un peu similaires. Aller de la mémoire, CVS est bon pour les personnes qui aiment utiliser des RCS dans leur référentiel de code local. RCS est agréable en ce que cela nécessite une vérification obligatoire d'un fichier. Cela vous rend explicitement conscient de quels fichiers que vous touchez à la fois. Il vous évite donc de "accidentellement" touchant la partie de quelqu'un d'autre du code.
Downvoting parce que Luke Skywalker dirait: "Incroyable. Chaque mot de ce qui était faux."
Wow. impressionnant. Vous m'avez ébloui par vos faits et votre logique. Par lesquels je veux dire, vous avez écrit zéro faits et logique, mais avons été descendus de toute façon. Avez-vous même utilisé des CV et des RCS pour travailler sur une base soutenue? J'ai utilisé tous les 3: CVS, RCS et Subversion, sur des projets étendus, pour le travail.
Oui, j'ai utilisé des CV et SVN sur des projets de travail. Vous voulez une liste d'erreurs que vous avez faites? Voici. "Il est inexact et trompeur de dire (Git / Subversion a été conçu pour résoudre les problèmes de CVS)." TORT. SVN a été explicitement conçu pour être un meilleur CVS (c'est-à-dire pour résoudre les problèmes de CVS, mais essentiellement de manière similaire). Git, otoh, était conçu pour un flux de travail différent. • "Aller de la mémoire, CVS est bon pour les personnes qui aiment utiliser des RCS dans leur référentiel de code local." TORT. Les CVS utilisent des fichiers RCS comme format de stockage de données, mais ne fonctionne pas comme des RCS.
"RCS est agréable en ce que cela nécessite une vérification obligatoire de sortir d'un fichier." TORT. La caisse exclusive obligatoire n'est pas une fonctionnalité intéressante. Il y a une raison que les VCS modernes ne fonctionnent pas de cette façon. Aussi probablement faux en ce que vous impliquez que les CVS fonctionne de cette façon, ce qu'il ne fait pas: le C en CVS signifie «simultané», car il ne nécessite pas de commande exclusive. L'idée de ne pas toucher "la partie de quelqu'un d'autre" du code est également problématique: tous les développeurs devraient être en mesure de changer tout nécessaire pour mettre en œuvre ce qu'ils font.
Apparemment, vous ne comprenez pas la signification relative des mots comme "Nice", et "faux". "Nice" est une déclaration d'opinion. La bonne réponse serait "Je ne suis pas d'accord sur le fait que c'est gentil". D'accord, vous ne voulez pas verrouiller obligatoire. C'est très bien. Certaines autres personnes le veulent cependant. Grandir et apprendre qu'il y a plus de choses au monde que de ce que vous voulez faire, et de ce dont vous avez besoin.