Différence entre GIT et CVS

Quelle est la différence entre les systèmes de contrôle de version Git et CVS?

J’utilise avec bonheur CVS depuis plus de 10 ans, et maintenant on m’a dit que Git était beaucoup mieux. Quelqu’un pourrait-il expliquer quelle est la différence entre les deux, et pourquoi l’un est meilleur que l’autre?

La principale différence est que (comme cela a déjà été dit dans d’autres réponses) CVS est un système de contrôle de version centralisé, alors que Git est dissortingbué.

Mais même si vous utilisez le contrôle de version pour un seul développeur, sur une seule machine (compte unique), il existe quelques différences entre Git et CVS:

  • Mise en place du référentiel Git stocke le référentiel dans le répertoire .git dans le répertoire supérieur de votre projet; CVS nécessite la configuration de CVSROOT, un emplacement central pour stocker les informations de contrôle de version pour différents projets (modules). La conséquence de cette conception pour l’utilisateur est que l’importation de sources existantes dans le contrôle de version est aussi simple que “git init && git add. && git commit” dans Git, alors qu’elle est plus compliquée dans CVS.

  • Opérations atomiques . Parce que CVS au début était un ensemble de scripts autour du système de contrôle de version RCS par fichier, les commits (et autres opérations) ne sont pas atomiques dans CVS; Si une opération sur le référentiel est interrompue au milieu, le référentiel peut être laissé dans un état incohérent. Dans Git, toutes les opérations sont atomiques: soit elles réussissent globalement, soit elles échouent sans aucune modification.

  • Changesets . Les modifications de CVS sont par fichier, tandis que les modifications (commits) dans Git se réfèrent toujours à l’ensemble du projet. C’est un changement de paradigme très important. Une des conséquences est qu’il est très facile dans Git de revenir (créer un changement qui annule) ou d’annuler tout le changement; Une autre conséquence est que, dans CVS, il est facile d’effectuer des vérifications partielles, alors qu’il est actuellement presque impossible dans Git. Le fait que les modifications soient par fichier, regroupées, a conduit à l’invention du format GNU Changelog pour les messages de validation dans CVS; Les utilisateurs de Git utilisent (et certains outils de Git attendent) des conventions différentes, avec une seule ligne décrivant les changements (résumant), suivie d’une ligne vide, suivie d’une description plus détaillée des modifications.

  • Nommer les révisions / numéros de version . Il y a un autre problème lié au fait que dans les modifications CVS sont des fichiers: les numéros de version (comme vous pouvez le voir parfois dans le développement de mots-clés , voir ci-dessous) comme 1.4 indiquent combien de fois le fichier a été modifié. Dans Git, chaque version d’un projet dans son ensemble (chaque validation) a son nom unique donné par l’identifiant SHA-1; les premiers 7 à 8 caractères suffisent généralement pour identifier un commit (vous ne pouvez pas utiliser un schéma de numérotation simple pour les versions du système de contrôle de version dissortingbué – qui nécessite une autorité de numérotation centralisée). Dans CVS pour avoir le numéro de version ou le nom symbolique faisant référence à l’état du projet dans son ensemble, vous utilisez des balises ; La même chose est vraie dans Git si vous voulez utiliser name comme ‘v1.5.6-rc2’ pour certaines versions d’un projet … mais les tags de Git sont beaucoup plus faciles à utiliser.

  • Branchement facile À mon avis, les succursales de CVS sont trop compliquées et difficiles à gérer. Vous devez étiqueter les twigs pour avoir un nom pour une twig entière du référentiel (et même cela peut échouer dans certains cas, si je me souviens bien, à cause de la gestion par fichier). Ajoutez à cela le fait que CVS n’a pas de suivi de fusion , vous devez donc vous souvenir, ou marquer manuellement les fusions et les points de twigment, et fournir manuellement les informations correctes pour “cvs update -j” pour fusionner les twigs. être inutile difficile à utiliser. Dans Git, créer et fusionner des twigs est très simple. Git se souvient de toutes les informations nécessaires (fusionner une twig est aussi simple que “git merge branchname “) … car le développement dissortingbué mène naturellement à plusieurs twigs.

    Cela signifie que vous pouvez utiliser des twigs de sujet , c’est-à-dire développer une fonctionnalité séparée en plusieurs étapes dans une twig distincte.

  • Renommer (et copier) le suivi . Les noms de fichier ne sont pas pris en charge dans CVS, et le renommage manuel peut rompre l’historique en deux ou entraîner un historique non valide dans lequel vous ne pouvez pas récupérer correctement l’état d’un projet avant de le renommer. Git utilise la détection de renommage heuristique, basée sur la similarité des contenus et des noms de fichiers (cette solution fonctionne bien dans la pratique). Vous pouvez également demander la détection de la copie de fichiers. Cela signifie que:

    • lors de l’examen de la validation spécifiée, vous obtiendrez des informations indiquant que certains fichiers ont été renommés,
    • la fusion prend correctement en compte les renom (par exemple, si le fichier a été renommé uniquement dans une twig)
    • “git blame”, l’équivalent (meilleur) de “cvs annotate”, un outil permettant d’afficher l’historique linéaire du contenu d’un fichier, peut également suivre le mouvement du code à travers les renoms
  • Fichiers binarys . CVS ne prend que très peu en charge les fichiers binarys (par exemple les images), obligeant les utilisateurs à marquer explicitement les fichiers binarys lors de l’ajout (ou plus tard de “cvs admin” ou via des encapsuleurs automatiques). fichier binary via la conversion de fin de ligne et l’extension du mot clé. Git détecte automatiquement le fichier binary en fonction du contenu de la même manière que diff le CNU et les autres outils le font. vous pouvez remplacer cette détection en utilisant le mécanisme gitatsortingbutes. De plus, les fichiers binarys sont sécurisés contre les gâchis irrécupérables grâce à la configuration par défaut de «safecrlf» (et au fait que vous devez demander une conversion de fin de ligne, bien que cela puisse être activé par défaut). l’expansion est un «opt-in» ssortingct dans Git.

  • Expansion des mots clés . Git propose un ensemble très limité de mots-clés par rapport à CVS (par défaut). Ceci est dû à deux faits: les modifications de Git sont par référentiel et non par fichier, et Git évite de modifier des fichiers qui n’ont pas changé lors du passage à une autre twig ou à un autre retour dans l’historique. Si vous souhaitez intégrer un numéro de révision à l’aide de Git, vous devez le faire en utilisant votre système de génération, par exemple en suivant l’exemple du script GIT-VERSION-GEN dans les sources du kernel Linux et dans les sources Git.

  • Modification commet . Parce que, dans VCS dissortingbué, tel que Git, le fait de publier est distinct de la création d’un commit, il est possible de modifier (éditer, réécrire) une partie non publiée de l’historique sans déranger les autres utilisateurs. En particulier si vous remarquez une faute de frappe (ou autre erreur) dans un message de validation, ou un bogue dans commit, vous pouvez simplement utiliser “git commit –amend”. Ce n’est pas possible (du moins pas sans le piratage lourd) dans CVS.

  • Plus d’outils Git offre beaucoup plus d’outils que CVS. Un des plus importants est ” git bisect ” qui peut être utilisé pour trouver une validation (révision) qui introduit un bogue; Si vos commits sont petits et autonomes, il devrait être assez facile de découvrir où se trouve le bogue.


Si vous collaborez avec au moins un autre développeur, vous constaterez également les différences suivantes entre Git et CVS:

  • Commit avant de fusionner Git utilise la méthode commit-before-merge plutôt que, comme CVS, merge-before-commit (ou update-then-commit ). Si pendant que vous éditez des fichiers, vous préparez pour créer un nouveau commit (nouvelle révision), quelqu’un d’autre a créé un nouveau commit sur la même twig et il est maintenant dans le repository, CVS vous oblige à mettre à jour votre répertoire de travail et à résoudre les conflits avant de vous engager. Ce n’est pas le cas avec Git. Vous commencez par valider, en enregistrant votre état dans le contrôle de version, puis vous fusionnez les autres modifications de développeur. Vous pouvez également demander à l’autre développeur d’effectuer la fusion et de résoudre les conflits.

    Si vous préférez avoir un historique linéaire et éviter les fusions, vous pouvez toujours utiliser le stream de travail commit-merge- recommit via “git rebase” (et “git pull –rebase”), qui est similaire à CVS en ce sens que vous relisez vos modifications. de l’état mis à jour. Mais vous vous engagez toujours en premier.

  • Pas besoin de référentiel central Avec Git, il n’y a pas besoin d’avoir un seul endroit central où vous validez vos modifications. Chaque développeur peut avoir son propre référentiel (ou de meilleurs référentiels: privé où il / elle fait du développement, et public dénudé où il / elle publie cette partie qui est prête), et ils peuvent extraire / récupérer les référentiels les uns des autres, en mode symésortingque. D’un autre côté, il est fréquent qu’un projet de grande envergure ait un référentiel central socialement défini / désigné à partir duquel tout le monde tire (obtenir des changements).


Enfin, Git offre beaucoup plus de possibilités lorsque la collaboration avec un grand nombre de développeurs est nécessaire. Ci-dessous, il y a des différences entre CVS in Git pour différentes étapes d’intérêt et de position dans un projet (sous contrôle de version avec CVS ​​ou Git):

  • lurker Si vous souhaitez uniquement obtenir les dernières modifications d’un projet ( pas de propagation de vos modifications ) ou faire du développement privé (sans consortingbuer aux projets originaux); ou vous utilisez des projets étrangers comme base de votre propre projet (les changements sont locaux et cela n’a pas de sens de les publier).

    Git prend en charge ici un access anonyme en lecture seule non authentifié via un protocole git:// efficace personnalisé, ou si vous êtes derrière un pare-feu bloquant DEFAULT_GIT_PORT (9418), vous pouvez utiliser le protocole HTTP simple.

    Pour CVS, la solution la plus courante (si je comprends bien) pour l’access en lecture seule est le compte invité pour le protocole «pserver» sur CVS_AUTH_PORT (2401), généralement appelé «anonyme» et avec un mot de passe vide. Les informations d’identification sont stockées par défaut dans le fichier $HOME/.cvspass , vous devez donc le fournir une seule fois. encore, il s’agit d’un peu de barrière (vous devez connaître le nom du compte invité, ou faire attention aux messages du serveur CVS) et la gêne.

  • développeur de franges (consortingbuteur de feuilles) . Un moyen de propager vos modifications dans OSS consiste à envoyer des correctifs par courrier électronique . C’est la solution la plus courante si vous êtes (plus ou moins) développeur accidentel, envoi de modification unique ou correction de bogue unique. BTW L’envoi de correctifs peut se faire via un tableau d’examen (système d’évaluation des correctifs) ou par des moyens similaires, et pas uniquement par courrier électronique.

    Git propose ici des outils d’aide à la propagation (publication) à la fois pour l’expéditeur (client) et pour le responsable (serveur). Pour les personnes souhaitant envoyer leurs modifications par e-mail, il existe un outil ” git rebase ” (ou “git pull –rebase”) pour relire vos propres modifications par-dessus la version amont actuelle. ), et ” git format-patch ” pour créer un courrier électronique avec un message de validation (et un auteur), changer sous la forme d’un format diff (étendu) unifié (plus diffstat pour une révision plus facile). Le responsable peut transformer ce courrier directement en commit en préservant toutes les informations (y compris le message de validation) en utilisant ” git am “.

    CVS ne propose pas de tels outils: vous pouvez utiliser “cvs diff” / “cvs rdiff” pour générer des modifications et utiliser le patch GNU pour appliquer les modifications, mais pour autant que je sache, il n’y a aucun moyen d’automatiser l’application des messages de validation. CVS était destiné à être utilisé dans le mode client <-> server …

  • lieutenant Si vous êtes responsable d’une partie distincte d’un projet (sous-système), ou si le développement de votre projet suit le stream de travail “réseau de confiance” utilisé dans le développement du kernel Linux … ou seulement si vous disposez de votre propre référentiel public vouloir publier sont trop volumineux pour envoyer par e-mail en tant que série de correctifs , vous pouvez envoyer une requête pull au responsable (principal) du projet.

    Cette solution est spécifique aux systèmes de contrôle de version dissortingbués , et CVS ne prend bien entendu pas en charge ce type de collaboration. Il existe même un outil appelé “git request-pull” qui aide à préparer le courrier électronique à envoyer au responsable avec la demande d’extraire de votre référentiel. Grâce à “git bundle”, vous pouvez utiliser ce mécanisme même sans repository public, en envoyant des modifications par e-mail ou par sneakernet. Certains sites d’hébergement Git tels que GitHub ont un support pour notifier que quelqu’un travaille (a publié un travail) sur votre projet (à condition qu’il utilise le même site d’hébergement Git), et pour PM-ing une sorte de requête pull.

  • développeur principal , c’est-à-dire quelqu’un qui publie directement ses modifications (dans le référentiel principal / canonique). Cette catégorie est plus large pour les systèmes de contrôle de version dissortingbués, car avoir plusieurs développeurs avec un access en écriture au référentiel central est non seulement un workflow possible (vous pouvez avoir un responsable unique qui pousse les modifications vers un référentiel canonique, un ensemble de responsables de lieutenants / sous-systèmes attire et un large éventail de développeurs de feuilles qui envoient des correctifs par courrier, soit à la liste de diffusion du responsable / projet, soit à l’un des lieutenants / sous-traitants).

    Avec Git, vous avez le choix d’utiliser le protocole SSH ( protocole git encapsulé dans SSH) pour publier les modifications, avec des outils tels que “git shell” (pour sécuriser l’access, limiter les comptes shell) ou Gitosis ), et HTTPS avec WebDAV, avec authentification HTTP ordinaire.

    Avec CVS, vous avez le choix entre un protocole pserver personnalisé (texte brut) ou un shell distant (où vous devez vraiment utiliser SSH ) pour publier vos modifications, ce qui signifie que vos modifications doivent être validées (création de commits). Eh bien, vous pouvez aussi tunneler le protocole ‘pserver’ avec SSH, et il y a trois outils de partie qui automatisent cela … mais je ne pense pas que ce soit aussi facile que par exemple Gitosis.

En général, les systèmes de contrôle de version dissortingbués, tels que Git, offrent une sélection beaucoup plus large de stream de travail possibles. Avec les systèmes de contrôle de version centralisés, tels que CVS, vous devez nécessairement faire la distinction entre les personnes ayant un access de validation au référentiel et celles sans … et CVS ne propose aucun outil pour accepter les consortingbutions (via des correctifs) commettre l’access.

Karl Fogel dans Producing Open Source Software dans la section sur le contrôle de version indique qu’il est préférable de ne pas fournir de contrôles trop ssortingcts, rigides et rigoureux sur les domaines où il est permis d’apporter des modifications au référentiel public; il est préférable de s’appuyer (pour cela) sur les ressortingctions sociales (telles que la révision du code) que sur les ressortingctions techniques; les systèmes de contrôle de version dissortingbués réduisent encore cet IMHO …

HTH (Hope That Helps)

Cet exposé de Linus (l’auteur original de git) résume bien la situation.

Google Tech Talks: Linus Torvalds sur Git

Attention: conversation très critique.

Git est un DVCS , par opposition à CVS qui est centralisé. La description simpliste sera la suivante: vous bénéficiez de tous les avantages du contrôle de version lorsque vous n’êtes connecté à aucun des référentiels possibles, et les opérations sont plus rapides.

Le site Web de Git explique probablement cela.

La fonctionnalité de mon animal de compagnie est de pouvoir faire des commits hors ligne. Et la vitesse, la vitesse fulgurante à laquelle tout, sauf pousser et tirer, se produit. (Et ces opérations sont par nature non destructives, vous pouvez donc pousser / tirer quand vous allez prendre un café si votre repository central est retardé.) Une autre chose intéressante est que les stacks sont incluses: le gitk gitk est un visualiseur assez bon; git gui est un bon outil de validation; avec la colorisation de la sortie, git add -i , git add -p , git rebase -i sont assez bonnes interfaces interactives; git daemon et git instaweb sont assez bons pour une collaboration ad hoc si vous ne voulez pas / ne pouvez pas manipuler votre repository central.

Je suis également un utilisateur heureux de cvs depuis plus de 10 ans, même si j’aime aussi git, et avec le temps, je vais le préférer, bien que la plupart des projets sur lesquels je travaille utilisent actuellement cvs, ou svn, et nous ne pouvons pas sembler pour obtenir la bureaucratie où je travaille convaincu de nous laisser percer un trou dans le pare-feu.

Les cvsps sont deux choses qui rendent les cvs plus sympathiques qu’elles ne le seraient autrement, et les scripts de patch d’Andrew Morton, ou quilt. Cvsps vous permet de reconstituer les fichiers multiples d’un commit dans un seul patch (et donc d’extraire les “changesets” de CVS) pendant le quilt, ou les scripts de patchs d’Andrew Morton vous permettent de commettre des “changesets” travailler simultanément sur plusieurs choses tout en les maintenant séparées avant de commettre. CVS a ses caprices, mais je suis habitué à la plupart d’entre eux.

“utiliser heureusement CVS depuis plus de x ans”, c’est une idée intéressante 🙂 C’est un énorme pas en avant de garder beaucoup de copies, mais …

Je suppose que vous vous êtes habitué à tout ce qui est bizarre, ou que vous ne faites pas beaucoup de twigment et de fusion. Il y a une pire possibilité.

Les personnes de votre organisation se sont habituées aux limitations du CVS et vos pratiques de travail se sont adaptées en conséquence;

par exemple, ne jamais avoir plus d’un développeur travaillant sur un seul paquet à la fois, n’utilisant que des twigs en cas d’urgence, etc.

Le principe de base est que plus quelque chose est difficile, moins les gens le font.