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 heureusement CVS depuis plus de 10 ans, et maintenant on me dit que Git est bien meilleur. Quelqu'un pourrait-il expliquer 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é (ancien), alors que Git est distribué.
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:
Configuration du référentiel . Git stocke le dépôt dans
.gitrépertoire dans le répertoire principal 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 que c'est plus compliqué dans CVS.Opérations atomiques . Comme CVS au début était un ensemble de scripts autour du système de contrôle de version RCS par fichier, les validations (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 rester dans un état incohérent. Dans Git, toutes les opérations sont atomiques: soit elles réussissent dans leur ensemble, soit elles échouent sans changement.
Changesets . Les modifications dans CVS s’effectuent par fichier, tandis que les modifications (commits) dans Git font toujours référence au projet dans son ensemble. Ceci est très important changement de paradigme. Une des conséquences de ceci est qu'il est très facile dans Git de revenir (créer un changement qui annule) ou d'annuler ensemble changement; Une autre conséquence est que, dans CVS, il est facile de faire des extractions partielles, alors qu’il est actuellement presque impossible dans Git. Le fait que les modifications soient regroupées par fichier et par fichier a conduit à l’invention de GNU pour les messages de validation dans CVS; les utilisateurs de Git utilisent (et certains outils Git s’y attendent)) une convention différente, avec une seule ligne de description. (résumant) changement, suivi d’une ligne vide, suivi d’une description plus détaillée des changements.
Nommer les révisions/numéros de version . Un autre problème est lié au fait que, dans CVS, les modifications s’appliquent par fichier: les numéros de version (comme vous pouvez le voir parfois dans expansion du mot clé, voir ci-dessous), comme 1.4 indique combien de fois le fichier a été donné. modifié. Dans Git, chaque version d’un projet dans son ensemble (chaque commit) a son nom unique donné par SHA-1 id; généralement, les premiers 7 à 8 caractères suffisent à identifier une validation (vous ne pouvez pas utiliser un schéma de numérotation simple pour les versions dans le système de contrôle de version distribué - nécessitant une autorité de numérotation centrale). Dans CVS, le numéro de version ou le nom symbolique faisant référence à l’état du projet dans son ensemble, vous utilisez des balises ; Il en va de même dans Git si vous souhaitez utiliser un nom tel que 'v1.5.6-rc2' pour une version d'un projet ... mais les balises dans Git sont beaucoup plus faciles à utiliser.
Branchement facile . À mon avis, les succursales dans CVS sont trop compliquées et difficiles à gérer. Vous devez baliser les branches pour avoir un nom pour toute une branche de 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 suivi de fusion, vous devez donc vous en souvenir, ou baliser manuellement les points de fusion et les points de branchement, et fournir manuellement les informations correctes pour "cvs update -j" fusionner des branches, ce qui rend la branche inutile et difficile à utiliser. Dans Git, créer et fusionner des branches est très simple. Git se souvient de toutes les informations requises par lui-même (donc fusionner une branche est aussi simple que "git merge nom de la branche") ... parce que le développement distribué conduit naturellement à plusieurs branches.
Cela signifie que vous pouvez utiliser branches de sujet, c’est-à-dire développer une fonctionnalité distincte en plusieurs étapes dans une branche distincte.
Renommer (et copier) le suivi . Les renommage de fichiers ne sont pas pris en charge dans CVS, et un renommage manuel peut briser l’historique en deux ou conduire à un historique invalide dans lequel vous ne pouvez pas récupérer correctement l’état d’un projet avant de le renommer. Git utilise une détection heuristique de changement de nom, basée sur la similarité du contenu et du nom de fichier (cette solution fonctionne bien dans la pratique). Vous pouvez également demander la détection de la copie de fichiers. Cela signifie que:
- en examinant le commit spécifié, vous obtiendrez des informations selon lesquelles un fichier a été renommé,
- la fusion prend correctement en compte les renommage (par exemple, si le fichier a été renommé uniquement dans une branche)
- "git blame", le (meilleur) équivalent de "cvs annotate", un outil permettant de visualiser l'historique des contenus d'un fichier, peut suivre le mouvement du code également lors du renommage
Fichiers binaires . CVS n’a qu’une prise en charge très limitée des fichiers binaires (par exemple, des images), obligeant les utilisateurs à marquer explicitement les fichiers binaires lors de l’ajout (ou plus tard en utilisant "cvs admin", ou via des wrappers le faisant automatiquement en fonction du nom de fichier) fichier binaire par conversion de fin de ligne et développement de mots clés. Git détecte automatiquement les fichiers binaires basés sur le contenu de la même façon que CNU diff et d’autres outils. vous pouvez remplacer cette détection en utilisant le mécanisme gitattributes. De plus, les fichiers binaires sont protégés contre les manipulations irrécupérables grâce à la valeur par défaut de 'safecrlf' (et au fait que vous devez demander une conversion en fin de ligne, bien que celle-ci puisse être activée par défaut en fonction de la distribution), et ce mot clé (limité) L’expansion est un strict "opt-in" dans Git.
Extension du mot clé . Git propose un ensemble de mots-clés très très limité par rapport à CVS (par défaut). Cela est dû à deux faits: les modifications dans Git s’appliquent à un référentiel et non à un fichier, et Git évite de modifier des fichiers qui n’ont pas été modifiés lors du passage à une autre branche ou lors du retour à un autre point de l’historique. Si vous souhaitez intégrer le numéro de révision à l’aide de Git, vous devez le faire à l’aide de votre système de construction, par exemple exemple suivant de script GIT-VERSION-GEN dans les sources du noyau Linux et dans les sources Git.
Modification des validations . Comme dans VCS distribué tel que Git act publishing 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 gêner les autres utilisateurs. En particulier, si vous remarquez une faute de frappe (ou une autre erreur) dans le message de validation, ou un bogue dans la validation, vous pouvez simplement utiliser "git commit --amend". Ceci n’est pas possible (du moins pas sans travaux lourds) 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) introduisant 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 la fusion Git utilise commit-before-merge plutôt que, comme CVS, merge-before -commit (ou update-then-commit). Si, pendant que vous éditiez des fichiers, prépariez la création d'un nouveau commit (nouvelle révision), une autre personne créait un nouveau commit dans la même branche et que celui-ci se trouvait maintenant dans le référentiel, CVS vous oblige à mettre à jour votre répertoire de travail et à résoudre les conflits avant de vous autoriser. 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 apportées aux développeurs. 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 commit-merge-recommit workflow via "git rebase" (et "git pull --rebase"), qui est similaire à CVS en ce que vous rejouez vos modifications en plus de l'état mis à jour. Mais vous vous engagez toujours en premier.
Pas besoin de référentiel central Avec Git, il n’est pas nécessaire d’avoir un seul endroit central pour valider vos modifications. Chaque développeur peut avoir son propre référentiel (ou de meilleurs référentiels: un répertoire privé dans lequel il/elle développe, et un répertoire public où il/elle publie la partie prête), et ils peuvent extraire/extraire les autres mode symétrique. D'autre part, il est courant qu'un grand projet ait socialement un référentiel central défini/nommé, d'où tout le monde tire (récupère les changements).
Enfin, Git offre beaucoup plus de possibilités lorsque la collaboration avec un grand nombre de développeurs est nécessaire. Ci-dessous, les différences entre CVS dans 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, ( aucune propagation de vos modifications ), ou faites privé = développement (sans contribuer aux projets originaux); ou vous utilisez des projets étrangers comme base de votre propre projet (les modifications sont locales et n’est pas logique de les publier).
Git prend en charge ici anonymous non authentifié un accès en lecture seule via une interface personnalisée personnalisée
git://protocol, ou si vous êtes derrière un pare-feu bloquantDEFAULT_GIT_PORT(9418), vous pouvez utiliser un HTTP simple.Pour CVS, la solution la plus courante (si j'ai bien compris) pour l'accès en lecture seule est compte invité pour 'pserver' protocole sur
CVS_AUTH_PORT_ (2401), généralement appelé "anonyme" et avec un mot de passe vide. Les identifiants sont stockés par défaut dans$HOME/.cvspassfichier, vous ne devez donc le fournir qu’une fois; c'est quand même un peu un obstacle (vous devez connaître le nom du compte invité, ou faire attention aux messages du serveur CVS) et la contrariété.développeur de franges (contributeur feuille) . Un moyen de propager vos modifications dans le logiciel libre consiste à envoyer des correctifs par courrier électronique . C'est la solution la plus courante si vous êtes (plus ou moins) un développeur accidentel, si vous envoyez un changement ou un seul correctif. BTW. L’envoi des correctifs peut se faire par l’intermédiaire d’un forum (système d’examen des correctifs) ou d’un moyen similaire, et pas uniquement par courrier électronique.
Git propose ici des outils qui aident ce mécanisme de propagation (publication) à la fois pour l'expéditeur (client) et pour le mainteneur (serveur). Pour les personnes qui souhaitent envoyer leurs modifications par courrier électronique, il existe un outil " git rebase " (ou "git pull --rebase") permettant de rejouer vos propres modifications par-dessus la version actuelle, de sorte que vos modifications sont activées. haut de la version actuelle (frais), et " git format-patch " pour créer un courrier électronique avec un message de validation (et son auteur), changez sous la forme du format diff unifié (étendu) (plus diffstat pour plus de facilité) la revue). Maintainer peut transformer ce courrier électronique directement en commit en préservant toutes les informations (y compris le message de commit) en utilisant " git am ".
CVS n’offre aucun de ces outils: vous pouvez utiliser "cvs diff"/"cvs rdiff" pour générer des modifications, et utiliser le correctif GNU pour appliquer des modifications, mais pour autant que je sache, automatiser l'application du message de validation. CVS devait être utilisé à la manière des clients <-> serveurs ...
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 flux de travail "réseau de confiance" utilisé dans le développement du noyau Linux ... ou simplement si vous avez votre propre référentiel public et les modifications que vous avez apportées. vouloir publier sont trop volumineux pour être envoyé par courrier électronique sous la forme série de correctifs, vous pouvez envoyer une demande d'extraction à (principal) responsable du projet.
Ceci est une solution spécifique aux systèmes de contrôle de versions distribué, donc bien sûr, CVS ne supporte pas ce type de collaboration. Il existe même un outil appelé "git request-pull" qui aide à préparer un courrier électronique à envoyer au responsable avec une requête à extraire de votre référentiel. Grâce à "git bundle", vous pouvez utiliser ce mécanisme même sans référentiel public, en envoyant un ensemble de modifications par e-mail ou par sneakernet. Certains sites d’hébergement Git tels que GitHub permettent de notifier que quelqu'un travaille (publie du travail) sur votre projet (à condition qu'il utilise le même site d'hébergement Git), et pour la gestion de type de demande de traction.
développeur principal , c’est-à-dire quelqu'un qui publie directement ses modifications (à référentiel principal/canonique). Cette catégorie est plus large pour les systèmes de contrôle de version distribués, car avoir plusieurs développeurs avec un accès en écriture au référentiel central n'est pas seulement un flux de travail possible (vous pouvez avoir un seul responsable qui pushes = modifications apportées au référentiel canonique, à un ensemble de lieutenants/mainteneurs de sous-systèmes d'où il tire, et à un large éventail de développeurs de feuilles qui envoient des correctifs par courrier à la liste de diffusion du mainteneur/projet, ou 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 aider la sécurité). , limitation de l’accès aux comptes Shell) ou Gitosis (pour gérer l’accès sans nécessiter de comptes Shell séparés), et [~ # ~] https [~ # ~] avec WebDAV, avec authentification HTTP ordinaire.
Avec CVS, vous avez le choix entre le protocole personnalisé non crypté (texte brut) pserver ou utiliser le protocole Shell distant (où vous devriez vraiment utiliser [~ # ~] ssh [~ # ~] ) pour publier vos modifications, ce qui signifie pour centralisé le système de contrôle de version signifie la validation de vos modifications (création de validations). Eh bien, vous pouvez également tunneler le protocole 'pserver' à l'aide de SSH, et il existe des outils tiers qui automatisent ce processus ... mais je ne pense pas que cela soit aussi simple que par exemple. Gitose.
En général, les systèmes de contrôle de version distribués, tels que Git, offrent un choix beaucoup plus large de flux de travail possibles. Avec les systèmes de contrôle de version centralisés, tels que CVS, vous devez obligatoirement faire la distinction entre les personnes disposant d'un accès au commit du référentiel et celles sans ... et CVS ne propose aucun outil permettant d'accepter des contributions (via des correctifs) provenant de personnes ne disposant pas commettre l'accès.
Karl Fogel dans Production de logiciels libres Dans la section consacrée au contrôle de version, il est préférable de ne pas mettre en place de contrôles trop stricts, rigides et rigoureux dans les domaines dans lesquels il est autorisé de modifier le référentiel public; il vaut beaucoup mieux s'appuyer (pour cela) sur des restrictions sociales (telles que la révision de code) que sur des restrictions techniques; Les systèmes de contrôle de version distribués réduisent encore davantage cet IMHO ...
HTH (espoir que cela aide)
Git est un DVCS , par opposition à CVS étant un système centralisé. La description simpliste sera la suivante: vous bénéficiez de tous les avantages du contrôle de version lorsque vous n'êtes pas connecté à aucun de plusieurs référentiels possibles. De plus, les opérations sont plus rapides.
Le site web de Git explique mieux cela probablement.
La fonction de mon animal de compagnie est de pouvoir effectuer des commits hors connexion. Et la vitesse, la vitesse fulgurante à laquelle tout se passe, sauf pousser et tirer. (Et ces opérations sont intrinsèquement non destructives, vous pouvez donc pousser/tirer quand vous allez prendre un café si votre dépôt principal est en retard.) Une autre bonne chose, c'est que les piles sont incluses: la fonction intégrée gitk est un bon assez de spectateur d'histoire; git gui est un outil de validation suffisant; avec colorisation en sortie, git add -i, git add -p, git rebase -i sont de bonnes interfaces interactives; git daemon et git instaweb sont suffisants pour une collaboration ad-hoc si vous ne voulez pas/ne pouvez pas tripoter votre référentiel central.
Je suis également un utilisateur plutôt content de cvs depuis plus de 10 ans, bien que j'aime aussi git, et que le temps viendra de le préférer, même si la plupart des projets sur lesquels je travaille utilisent actuellement cvs, ou svn, et nous ne pouvons pas sembler pour obtenir la bureacracy où je travaille convaincu de nous laisser percer un trou à travers le pare-feu.
Quelques éléments qui rendent cvs plus agréable qu’il pourrait être autrement sont cvsps, et un autre est soit les scripts de patch d’Andrew Morton, soit le quilt. Cvsps vous permet de reconstituer les multiples fichiers d’un commit en un patch unique (et d’extraire ainsi les "changesets" de CVS) pendant la courtepointe, ou les scripts de patch d’Andrew Morton vous permettent de travaillez simultanément sur plusieurs choses tout en les maintenant séparées avant de vous engager. CVS a ses bizarreries, mais je suis habitué à la plupart d'entre elles.
"utiliser joyeusement CVS depuis plus de x ans", est une idée intéressante :-) C'est un énorme pas en avant en conservant beaucoup de copies, mais ...
Je suppose que vous êtes habitué à toutes ses bizarreries ou ne faites pas beaucoup de ramifications et de fusions. Il y a une pire possibilité;
Les membres de votre organisation se sont habitués aux limitations CVS et vos pratiques de travail se sont adaptées en conséquence.
par exemple, ne jamais avoir plus d'un développeur travailler sur un package à la fois, en utilisant uniquement la création de branches en cas d'urgence, etc.
Le principe de base est que plus il est difficile, moins les gens le font.