Dans cet article, on va expliquer les bases d’un système SVN en commençant par les problèmes rencontrés et voir comment ce genre de systèmes permet de les résoudre en expliquant ses notions de bases introduites.
Problématique
Lors d’un projet de développement, on écrit chaque jour de nouvelles lignes de code ou modifie des lignes existantes, si vous travaillez au sein d’une équipe, vous avez surement été responsable d’une nouvelle fonctionnalité pendant que votre collègue corrige un bug rencontré (Un exemple parmis plusieurs), vous avez tout les deux agit sur différents fichiers et il va falloir par la suite synchroniser vos modifications.
Cependant plus le nombre d’intervenants dans le projet est grand, plus la tâche de synchronisation devient difficile.
Autre cas, vous pouvez parfois agir sur les mêmes fichiers et que vos modifications soient incompatibles entre-elles. Dans ce cas, la résolution demandera un effort considérable.
Si vous n’avez jamais utilisé un outil de contrôle de versions, vous avez peut-être rencontré l’un de ces problèmes ou surement l’un des suivants :
- Ne pas savoir quelles sont les modifications exactes disponibles actuellement pour les utilisateurs.
- Avoir eu recours à des suffixes comme “_final” , “_v1” , “_v2” … pour différencier les versions de votre code, généralement on finit par avoir des “final1, final2 …” et puis on perd rapidement le fil.
- Ne pas savoir quelles sont les modifications apportées à la version Y par rapport à la version X.
- Avoir commenté un bout de code sans le supprimer de peur que vous l’ayez besoin plus tard dans le projet.
Le contrôle de versions permet de résoudre ce genre de problèmes.
Définitions et concepts SVN
Subversion (appelé souvent SVN) est un logiciel de gestion de sources et de contrôle de versions qui agit sur une arborescence de fichiers en conservant leurs différentes versions, ainsi que les différences entre-elles.
Ce type de logiciel facilite le travail collaboratif sur un projet de développement et permet de restaurer rapidement une versions précédente du code pour pouvoir l’analyser, savoir les modifications apportées, Quand ? Par qui ? Dans quel fichier ? Et à quelle ligne ? (Pratique, non ?)
SVN agit selon le modèle Client-Serveur et donc on trouve dans un système SVN :
- Un serveur centrale contenant :
- Un ensemble de dépôts ou référentiels (« repository » en anglais).
- Un ou plusieurs clients (SmartSVN, TortoiseSVN) dont le rôle est :
- Copier les fichiers depuis le serveur pour pouvoir les modifier localement.
- Synchroniser, envoyer les modifications effectuées sur le serveur SVN.
Le référentiel (Repository) : C’est le point centrale d’un système SVN, c’est là ou se trouve l’ensemble des fichiers de nos projets.
Un client SVN lit ou recopie des données à partir du référentiel, il ne voit normalement que la dernière version de vos fichiers. Mais ce qui rend un système SVN intéréssent, c’est qu’à partir de votre client SVN, vous pouvez avoir les versions précédentes d’un fichier, ou bien avoir l’état d’un ou de l’ensemble des fichiers à un jour précit …, savoir qui a efféctué la dernière modification sur un fichier et quelle est cette modification.
==> C’est ce genre de possibilités qui caractérisent un système SVN !
La copie de travail (Working copy) : C’est le répertoire local obtenu lors d’une copie des données du référentiel moyennant un client SVN. Le développeur pourra ainsi agir sur le répertoire local puis l’envoyer vers le dépôt, ainsi il fera l’objet d’une nouvelle révision.
Une révision : Comme on vient de le dire, chaque changement envoyé au référentiel constituera une révision. La révision est caractérisée par un nombre de version (1,2,3…) qui fera la différence par rapport à la révision précédente.
Les principales commandes SVN
Les principales commandes SVN sont les suivantes : (un exemple en détail de chaque commande sera ajouté pus tard)
| add | Déclare l’ajout d’une nouvelle ressource pour le prochain commit. |
| blame | Permet de savoir quel contributeur a soumis les lignes d’un fichier. |
| checkout (co) | Récupère en local une version ainsi que ses méta-données depuis le dépôt. |
| cleanup | Nettoie la copie locale pour la remettre dans un état stable. |
| commit (ci) | Enregistre les modifications locales dans le dépôt créant ainsi une nouvelle version. |
| copy | Copie des ressources à un autre emplacement (localement ou dans le dépôt). |
| delete | Déclare la suppression d’une ressource existante pour le prochain commit (ou supprime directement une ressource du dépôt). |
| diff | Calcule la différence entre deux versions (permet de créer un patch à appliquer sur une copie locale). |
| export | Récupère une version sans métadonnées depuis le dépôt ou la copie locale. |
| import | Envoie une arborescence locale vers le dépôt. |
| info | Donne les informations sur l’origine de la copie locale. |
| lock | Verrouille un fichier. |
| log | Donne les messages de commit d’une ressource. |
| merge | Calcule la différence entre deux versions et applique cette différence à la copie locale. |
| move | Déclare le déplacement d’une ressource. |
| propdel | Enlève la propriété du fichier. |
| propedit | Édite la valeur d’une propriété. |
| propget | Retourne la valeur d’une propriété. |
| proplist | Donne une liste des propriétés. |
| propset | Ajoute une propriété. |
| resolved | Permet de déclarer qu’un conflit de modifications est résolu. |
| revert | Revient à une version donnée d’une ressource. Les modifications locales sont écrasées. |
| status (st) | Indique les changements qui ont été effectués. |
| switch | Bascule sur une version/branche différente du dépôt. |
| update (up) | Met à jour la copie locale existante depuis la dernière version disponible sur le dépôt. |
| unlock | Retire un verrou. |
Nous n’entamerons pas dans cet article l’étape d’installation d’un serveur SVN, toutefois nous vous recommandons de suivre le guide de collabnet disponible sur le lien suivant : http://www.collab.net/lightbox/download_info/61/34
Une fois votre serveur SVN est mis en place, voici une vidéo intéressante qui détail les opérations de base qu’on peut faire.
Bonnes pratiques SVN
Avant de finir notre article à propos de SVN, voici une liste non exhaustive mais recommandée lors de votre travail :
- Mettez à jour votre copie de travail avant de la modifier.
- Testez votre code avant de l’envoyer sur le référentiel distant.
- Envoyer vos modifications dans le référentiels distant dès que vous avez terminé le travail sur une tâche/fonctionnalité. (si au cours du développement de cette fonctionnalité vous avez modifié trois fichiers, attendez la fin du développement pour envoyer le tout et évitez d’envoyer votre code à chaque modification d’un fichier)
- N’envoyer un code que si vous avez effectué des modifications dessus.
- Chaque envoie doit être accompagné d’une description détaillant la nature et le but des modifications effectuées.
- Si vous utilisez un système de suivi de bugs comme Jira, précisez l’ID du bug dans la description.
Voici un livre qui vous aidera à maîtriser plus SVN
