Quelle est la valeur des commits atomiques dans Subversion?

Question

J'essaie de créer et de suivre les meilleures pratiques pour le contrôle de la gestion des versions et je suis tombé sur une référence aux commits atomiques dans Subversion. Puisque je n'ai jamais entendu parler de cette action, j'ai quelques questions à ce sujet.

• Quel est son but?
• Quand devrait-il être utilisé?
• En quoi est-ce différent d'un commit normal? Il est disponible pour TortoiseSVN utilisateurs? Si c'est le cas, comment?

Answer 1

Il n'existe aucune commande spéciale pour les validations atomiques. Chaque commit dans Subversion est atomique.

Cela signifie que chaque validation (d'un nombre quelconque de fichiers) réussira ou échouera dans son ensemble.
Il n'est pas possible que seuls certains des fichiers validés parviennent au référentiel et d'autres pas (par exemple, en raison d'une erreur survenue au milieu de l'opération de validation ou d'un conflit dans l'un des fichiers).

Il en est de même pour TortoiseSVN, car il s'appuie sur la fonctionnalité Subversion "normale".

---

Voici un extrait du Subversion book:

Une opération svn commit publie des modifications à un certain nombre de fichiers et répertoires comme une seule transaction atomique . Dans votre copie de travail, vous pouvez modifier le contenu des fichiers; créer, supprimer, renommer et copier des fichiers et des répertoires ; puis validez un ensemble complet de modifications en tant que transaction atomique .

Par transaction atomique, nous voulons simplement dire ceci: soit tous les changements se produisent dans le référentiel, ou aucun d'entre eux arrive. Subversion tente de conserver cette atomicité face au programme des plantages, des pannes système, des problèmes de réseau , et d'autres actions des utilisateurs.

Answer 2

Le terme "atomique" désigne dans ce cas une opération atomique. Vous pouvez trouver une bonne définition de cela ici: http://en.wikipedia.org/wiki/Atomic_operation

Toutes les validations dans SVN sont automatiquement atomiques, donc vous l'obtenez gratuitement partout où vous faites un commit.

Answer 3

L'idée est simplement que les modifications apportées à un fichier sont généralement liées aux modifications d'un autre. Certains anciens systèmes de contrôle de version ne géraient pas vraiment plusieurs fichiers dans un seul commit (en tant que "commit atomique" comme vous l'appelez) ou ils le faisaient mal.

Vous n'avez rien de spécial à faire pour cela. C'est ainsi que fonctionne Subversion. Mais avec Subversion vous avez la possibilité de vérifier dans un fichier à la fois ou de faire tous les fichiers modifiés à la fois ou n'importe où entre les deux.L'idée de faire plusieurs fichiers en une seule validation est que — en général — vous devriez être en mesure de vérifier le référentiel à une version particulière et il sera au moins compiler et, espérons-le, fonctionner. C'est important dans les équipes. Maintenant, dans la pratique, cela peut ne pas être vrai 100% du temps mais le principe directeur est le son. Donc, que vous fassiez un fichier, tous vos changements à la fois ou quelque chose entre ce que vous vérifiez devrait être une validation. Comme si vous corrigiez un bogue et que vous deviez modifier 8 fichiers, archivez tous ces 8 fichiers comme un commit avec un message indiquant quel bug vous avez corrigé et comment vous l'avez corrigé. Ce sera plus facile à déployer plus tard s'il y a un problème.

Answer 4

Si vous voulez savoir à quoi servent les validations atomiques, imaginez que vous fusionniez une branche dans le tronc de votre disque. Vous commencez le matin et après le déjeuner vous avez terminé, tout compile, et tous les tests unitaires se déroulent avec succès. Vous validez ensuite les 200+ fichiers modifiés lors de cette fusion.

Dans SVN, la validation réussit et tous les fichiers 200+ sont validés en une fois ou la validation échoue et aucune modification n'a été apportée au référentiel. (Il n'y a pas grand chose de plus à dire à ce sujet.)

Dans CVS, qui n'a pas de commits atomiques, il peut arriver que votre commit soit interrompu après 150 fichiers parce que Quelqu'un a trébuché sur votre câble réseau, les 50 fichiers restants n'ayant pas été validés, laissant le référentiel dans un état intermédiaire. Pendant que vous essayez de brancher votre câble réseau, un autre membre de votre équipe vérifie un autre ensemble de modifications. Cet ensemble de changements est disjoint de ceux que vous avez déjà enregistrés, donc la validation de l'autre personne réussit. Cependant, les changements sont incompatibles. Maintenant, l'équipe est bloquée avec un référentiel qui contient du code qui ne compile même pas, sans parler de tout test. Pire encore: vous avez tous les deux un manager d'équipe qui vous souffle le cou pour corriger ces changements aussi rapidement que possible afin que le reste de l'équipe puisse arrêter de jouer à Quake et se remettre au travail. Etonnamment, de tels scénarios ne sont pas aussi improbables que cela puisse paraître. J'y suis allé plusieurs fois et j'ai eu ma collection de chemises moche.

Answer 5

Pour comprendre la véritable utilisation de livraison atomique, lire sur l'intégration continue:

http://en.wikipedia.org/wiki/Continuous_integration

L'utilisation est vraiment à faire en sorte que vous pouvez annuler tous les changements d'un développeur spécifique en cas de problème d'intégration . C'est une fonctionnalité très puissante pour garder l'intégrité du code dans le référentiel.