Subversion Numéro de révision

Question

Je n'ai jamais travaillé avec un VCS, alors corrigez-moi si je commets des erreurs fondamentales.

Pour un de mes projets, j'ai choisi d'utiliser Subversion, et j'ai lu la documentation. Si je comprends bien, le numéro de révision est incrémenté pour chaque enregistrement. Cependant, cela soulève une question. Est-il possible de vérifier plus d'un fichier à la fois (donc l'incrément est seulement un)? De plus, que se passe-t-il si, par exemple, un checkin ne compile pas ... le numéro de révision sera-t-il incrémenté?

Answer 1

Est-il possible de vérifier plus d'un fichier à la fois (donc l'incrément est seulement un)?

Oui, cela est possible. Voir Does Subversion have Changesets? de la FAQ officielle.

De même, que se passe-t-il si, par exemple, un checkin ne compile pas ... le numéro de révision sera-t-il incrémenté?

Vous testeriez d'abord si l'état actuel des choses est compilé dans votre environnement de test, et vérifiez si c'est le cas.

Vous pouvez automatiser cela en utilisant un pre-commit hook qui exécute vos tests, et à cette condition continue avec l'enregistrement.

Answer 2

Le numéro de révision est atomique, ce qui signifie qu'il s'applique à toute la série de modifications pour un seul commit, en incrémentant le numéro de révision de un à la fois. Le numéro de révision serait incrémenté, qu'il compile ou non, car Subversion n'a aucune connaissance ou association avec votre pile technologique spécifique afin de déterminer si la compilation est réussie ou non.

En général, vous ne commettrez pas s'il ne compile pas localement. Si vous le faites, vous 'casser la construction', et devrait mettre de l'argent dans l'équipe 'minou'. ;-)

Answer 3

Oui, vous pouvez vérifier dans plusieurs fichiers à la fois, et cela n'incrémenter la révision par 1.

Dans votre deuxième question, je ne pense pas que vous voulez dire « compiler », depuis la révision les systèmes de contrôle ne se soucient pas de savoir si le code qu'ils contrôlent est compilable ou non. Je pense que vous voulez dire "commettre". Dans ce cas, la réponse est que les commits de subversion sont atomiques. Ils fonctionnent complètement ou échouent complètement. Il est impossible de tenter une validation multi-fichiers et d'avoir des fichiers réussis mais pas d'autres. Une validation échouée n'incrémente pas le numéro de révision.

Answer 4

Les validations de Subversion sont transactionnelles. Soit la validation entière réussit, soit la validation entière échoue. Si la validation réussit, le numéro de révision est incrémenté. Donc, tout votre commit, quel que soit le nombre de fichiers qu'il contient, augmentera le nombre de révision de 1.

Subversion n'a aucun moyen de savoir si votre code est compilé. Donc, si vous commettez un code cassé, alors vous commettez du code cassé, mais le numéro de révision augmente encore. Vous ne pouvez pas annuler un commit (au moins, pas facilement et pas sans inconvénient considérable).

Si vous avez besoin d'un serveur de build, je peux vous recommander JetBrains TeamCity. TeamCity est livré avec un plugin VisualStudio qui vous permet de faire un 'commit pré-testé'. Autrement dit, vous soumettez votre code au serveur de génération TeamCity, qui génère le code.Si (et seulement si) la construction réussit, alors TeamCity valide vos changements à Subversion pour vous. Si la construction échoue, TeamCity vous avertit et ne valide pas le code. Cela fonctionne bien et permet d'éviter d'embarrasser les builds cassés :)

Answer 5

Certains systèmes de contrôle de version utilisent un numéro de révision pour chaque fichier. Subversion utilise un numéro de révision unique pour l'ensemble du référentiel. Lorsque vous effectuez une validation, Subversion peut valider les modifications apportées à un seul fichier, à plusieurs fichiers ou même à tous les fichiers modifiés depuis la dernière extraction (voir la documentation pour svn add, svn revert et svn commit). Subversion traite le commit comme une transaction atomique; c'est-à-dire, peu importe le nombre ou le nombre de fichiers que vous commettez, tous sont engagés en une seule opération qui réussit complètement ou échoue complètement (dans ce cas, le référentiel n'est pas modifié). Chaque fois que vous émettez une commande de validation, le numéro de révision de l'ensemble du référentiel augmente. Subversion ne sait pas si votre code compile ou pas, donc rien ne vous empêche de vérifier le mauvais code. Vous pouvez utiliser Subversion pour stocker n'importe quel type de fichier, pas seulement le code source, donc Subversion n'essaie pas de vérifier la fonctionnalité de tout ce que vous archivez (puisque tenter de "construire" un référentiel plein de fichiers texte n'a pas de sens et car il n'y a pas de moyen fiable pour le serveur de deviner votre système de construction ou comment compiler votre code). Cela étant dit, il est possible d'indiquer au serveur Subversion d'exécuter un script chaque fois qu'une validation est tentée mais avant que la transaction ne soit traitée (appelée hook de pré-validation). Certaines personnes utilisent cette fonctionnalité avec un script qui tente de générer le code source (y compris les modifications entrantes). Si le script ne parvient pas à générer la source, il renvoie une erreur et Subversion refuse la transaction (de votre côté, l'opération de validation échoue). Le code source auto-construction n'est pas quelque chose qui est intégré dans Subversion par défaut, mais il n'est pas trop difficile à ajouter si c'est quelque chose qui vous intéresse.

Pour plus d'informations, je vous recommande fortement de lire le (gratuit) livre officiel Subversion "Version Control with Subversion". C'est une lecture facile, contient presque tout ce que vous voulez savoir sur Subversion, et a beaucoup d'exemples.