Une des raisons pour lesquelles les programmeurs préfèrent SVN à CVS est-ce que le premier autorise les commits atomiques? Qu'est-ce que ça veut dire ?
Une des raisons pour lesquelles les programmeurs préfèrent SVN à CVS est-ce que le premier autorise les commits atomiques? Qu'est-ce que ça veut dire ?
Réponses:
Cela signifie que lorsque vous effectuez une validation dans le système de contrôle de version, tout ce que vous voulez valider est inclus OU rien ne le sera.
Dans CVS, lorsque vous essayez de valider, il est possible que la validation réussisse sur plusieurs fichiers, puis échoue sur plusieurs autres (car ils ont changé). Cela laisse le dépôt dans un état malheureux car la moitié de votre commit n'y est pas, et il est probable que vous ayez laissé des choses dans un état où elles ne compileraient pas ou pire. Maintenant, vous devez vous dépêcher et intégrer toutes les modifications afin de pouvoir valider les autres fichiers avant que quelqu'un d'autre ait besoin de mettre à jour et d'obtenir votre ensemble de modifications cassé.
Cela ne se produira pas dans SVN - SVN engagera tout ce que vous avez modifié ou échouera dans son ensemble de modifications. Ainsi, vous ne laisserez jamais le référentiel dans un état de panne en raison de problèmes de validation.
Ceci est expliqué par exemple dans Bye-bye CVS. J'ai été Subverted article écrit par Andy Lester :
Si j'essaie de valider dans Subversion, mais si l'un des fichiers est en conflit ou obsolète, aucun des fichiers ne sera validé. Dans CVS, vous avez un ensemble de fichiers à moitié dédié que vous devez corriger RIGHT NOW.
Le fait que CVS oblige le programmeur à réparer immédiatement la fusion est aussi contre-productif que possible. Par rapport à cela, une option permettant de retarder / annuler / fusionner soigneusement les modifications constitue un avantage substantiel.
Les autres avantages de SVN par rapport à CVS, décrits dans l'article ci-dessus, sont les suivants:
Les versions locales de tout ce que vous faites
Si vous voulez utiliser cvs diff, vous devez pouvoir vous connecter à votre référentiel. Pas de connexion internet, pas de diffing. Subversion stocke des copies immaculées locales de ce sur quoi vous travaillez, donc svn diff fonctionnera parfaitement. Voulez-vous recommencer? svn revert fonctionne aussi sans lien.Noms symboliques des révisions
HEAD est le nom de la pointe du tronc dans CVS, mais j'ai toujours voulu pouvoir dire «-r-1» comme si je pouvais revenir en arrière lorsque nous étions en PVCS. Avec CVS, je dois créer un journal CVS sur ce que je suis en train d’éditer, puis en soustraire un. Ce n'est pas amusant. Avec Subversion, je peux dire svn diff -r PREV.Rapport d'état réel
Dans CVS, la seule façon de savoir si quelque chose est plus récent sur le serveur consiste à mettre à jour cvs et à espérer que quoi que ce soit qui ne se produit ne provoque pas de conflit. Avec la commande svn status, je reçois un statut réel, ce qui me permet de voir s'il y a des conflits AVANT de faire une mise à jour.Traitement utile des conflits de fusion
Dans CVS, s'il existe des conflits, vous obtenez des marqueurs de conflit dans votre fichier. Dans Subversion, vous obtenez des marqueurs de conflit, PLUS une copie de votre fichier pré-conflit original, PLUS la version du serveur, PLUS la version que vous aviez initialement modifiée. Ensuite, vous devez explicitement svn résoudre filename.txt pour indiquer à Subversion que vous avez résolu le problème. Plus aucun retour accidentel dans CVS avec des marqueurs de conflit toujours là.
Cela signifie que toutes les modifications apportées à tous les fichiers sont validées en une seule transaction. Par conséquent, toutes les opérations aboutissent ou aucune.
Cela signifie que vous êtes moins susceptible d’obtenir des modifications partielles archivées dans le référentiel, ce qui entraîne l’échec des générations. Vous pouvez toujours amener les gens à oublier d’archiver tous les fichiers pertinents, mais c’est un problème de processus plutôt qu’un problème avec le système de gestion de versions.