Utilisation de SVN
Mise en place du serveur 3
Installation de Visual SVN Server version gratuite 3
Création de l'arborescence d'un repository 3
Utilisation sur un poste de développeur 5
Installation de Tortoise SVN 5
Récupération du contenu d'un repository 6
Quand utiliser le tronc, un tag ou une branche ? 8
Update 8
Update to revision 9
Diff 9
Commit 9
Revert 10
La commande blame 10
Création d'une branche 10
Création d'un tag 10
Récupération d'une branche, d'un tag ou du tronc 10
Utilisation sur le serveur Linux 11
Connaître la version d'un fichier 11
Mettre à jour un fichier à une version précise 11
Mise en place du serveur
L'outils Visual SVN Server est une version " visuelle " du serveur SVN, qui tourne sous Windows. Le côté " visuel " permet une administration simplifiée, ce qui évitera d'avoir une personne spécialement formée sur l'outil serveur, et des procédures complexes pour sa maintenance.
Cet outil existe en deux version : la première est gratuite, et suffisante pour l'utilisation actuelle chez X. La seconde, qui présente quelques fonctionnalités supplémentaire, notamment en terme d'authentification et de traçage des actions sur le serveur, est payante (950$ au 07/09/2012)
On peut télécharger et trouver plus d'informations sur cet outil à l'adresse suivante :
http://www.visualsvn.com/server/
Installation de Visual SVN Server version gratuite
Il n'y a rien de particulier à dire quant à l'installation du serveur : l'installation se fait avec un assistant d'installation classique. On choisi l'emplacement des fichiers programme et l'emplacement des repository. On choisira ces deux dossiers en fonction du plan de sauvegarde et de gestion des données du serveur :
- Les fichiers programmes peuvent être perdus et remplacés par une nouvelle installation
- Les fichiers repository, qui peuvent prendre pas mal de place avec le temps, doivent être sauvegardés régulièrement, et peuvent à tout moment être montés sur une installation fraîche de SVN Server, quel que soit l'éditeur.
Création de l'arborescence d'un repository
A chaque nouveau projet, on va créer un nouveau repositorty et son arborescence.
Le nom du repository portera le nom du projet, et on laissera l'outil créer l'arborescence par défaut, constituée de trois dossiers " trunk / branches / tags ".
Utilisation sur un poste de développeur
SVN est originalement un outil qui fonctionne exclusivement en ligne de commande.
Cependant, un éditeur propose gratuitement une surcouche totalement intégrée à l'explorateur Windows (compatible à partir de Windows XP SP3).
Cette édition permet de manipuler de façon visuelle le client SVN, de façon très simplifiée, et permet notamment de rentre plus aisées certaines tâches rébarbatives (sélection multiple de fichiers, résolution des conflits, etc.)
On trouve le logiciel gratuit Tortoise SVN à l'adresse suivante :
http://tortoisesvn.tigris.org/
On peut installer la version 32 ou 64 bits indifféremment, cela n'a aucune incidence quant à la compatibilité avec la version serveur.
Régulièrement, lorsqu'on utilise Tortoise SVN, un message rouge apparaît indiquant la sortie d'une nouvelle version. Il n'est pas obligatoire d'installer toujours la dernière version, mais conseillé : les outils de merge sont régulièrement améliorés, et l'ergonomie générale évolue aussi régulièrement.
Installation de Tortoise SVN
Lors de l'installation de Tortoise SVN, un assistant vous guide. Il faut choisir les paramètres d'installation " Personnalisés ".
Dans la liste des composants à installer, on peut tout cocher, ou décocher " Icônes supplémentaires ", et les deux dictionnaires " Américain " et " Anglais ". On peut aussi cocher, si on le désire, les outils de ligne de commande. Il s'agit du client SVN " classique " qu'on peut utiliser en ligne de commande.
A la fin de l'installation, le logiciel vous demandera certainement de redémarrer. Ce n'est pas obligatoire, mais préférable pour bénéficier immédiatement de toutes les fonctionnalités.
Récupération du contenu d'un repository
Après avoir créé un dossier vide dans l'explorateur Windows, cliquez-droit dessus et choisissez " SVN Checkout " :
Dans le champ " URL of repository ", entrez l'adresse du serveur SVN suivi de " /svn/nomprojet ", puis cliquez sur le bouton " … " pour parcourir ses repositories.
Puis choisissez si vous voulez le tronc " trunk ", une branche ou un tag en particulier :
Vérifier que Checkout depth est bien sur " Fully recursive ". Dans la partie " Revision ", choisissez " HEAD " si vous voulez la dernière version des sources, ou choisissez une version en particulier.
Le programme télécharge alors l'ensemble des fichiers du repository.
Attention, ceci peut prendre pas mal de temps, surtout si le volume des fichiers est important.
Quand utiliser le tronc, un tag ou une branche ?
Avant chaque modification, que ce soit une évolution ou une correction, il faut se poser la question de la version qu'on souhaite mettre à jour.
En effet, si on est en train de modifier le fichier " bienvenue.htm " dans le cadre d'une évolution (iWork), et qu'un bug survient sur ce même fichier sur la production, que faire ? Corriger la version en cours de modification introduira une partie du nouveau développement (iWork) lors de la mise en production, ce qu'on ne veut surtout pas faire. Que faire aussi si la mise en place de l'iWork est longue et qu'une demande SOD-10 est à traiter rapidement ?
La gestion du tronc, des branches et des tags est là pour nous sauver la mise.
En règle générale :
Le tronc est la partie " vivante " du programme. On l'utilisera pour tout ce qui est développement à cycle rapide : petits iWork et SOD-10, ainsi que des corrections.
Les branches sont la partie " alternative " du programme. On les utilisera lors du développement d'un iWork de taille conséquente : mise en place d'un nouveau portail EGX, refonte du flux de commande, etc. Elles servent à travailler sur une version alternative du code, afin de ne pas gêner le cycle d'éventuels iWork, SOD-10 ou corrections qui pourraient être demandés avant la mise en place finale du projet.
Les tags sont des versions " figées " du programme. A chaque livraison des sources sur l'environnement de recette, on doit créer un tag. Ceci permet, sans être impacté par d'éventuels développements, d'apporter une correction à la version qui se trouve en production.
Un tags est par définition en lecture seule. On peut donc récupérer les sources d'une version de production, mais on ne pourra pas commiter les modifications apportées sur le tag : la version 1.0 d'un CD est la version qui se trouve sur un CD. Si on livre un correctif, ce n'est plus la version 1.0, mais la version 1.0.1 ou 1.0 SP1 par exemple.
Une fois le tag corrigé, on créera une nouvelle branche, qui correspondra aux corrections effectuées sur la production. Et lors de la livraison, on créera un nouveau tag, à partir duquel il faudra repartir si on doit faire une nouvelle correction.
Une branche évoluant parallèlement au tronc, mais ayant pour vocation d'être un jour réintroduite dans le tronc, il convient de faire des merges réguliers depuis le tronc vers les branches. Idéalement, à chaque modification du tronc, il faut mettre à jour les branches, afin de réduire les risques de conflits.
Une fois un développement dans une branche terminé, il faut merger la branche vers le tronc. C'est à dire qu'on applique au tronc l'ensemble des modifications apportées dans la branche.
Après chaque modification d'un tag, il faudra faire un merge vers le tronc et l'ensemble des branches actives, afin de propager la correction : il ne faudrait surtout pas qu'on réintroduise le bug à la mise en production suivante…
Update
Update peut être fait sur un fichier en particulier, un groupe de fichiers, ou un dossier.
Avant de travailler sur le tronc ou une branche, il faut s'assurer qu'on dispose bien de la dernière version des fichiers.
Il faut donc aller sur la racine du projet, faire click-droit dessus, et sélectionner " SVN Update ".
Si vous avez modifié un fichier et que vous ne l'avez pas commité, mais que SVN dispose d'une version plus récente, il va apparaître en conflit.
Vous pouvez alors résoudre le conflit de façon semi-automatique. Un écran de type " WinMerge " apparaît, et affiche la version " base " (celle du serveur) et la version " working copy " (votre version) en mettant en évidence les différences.
Il vous appartient alors de choisir si vous voulez conserver, pour chaque différence :
- la version " base "
- votre version
- les deux l'une en dessous de l'autre, dans l'ordre que vous désirez
Une fois le conflit corrigé, il suffit d'indiquer à SVN que le conflit est résolu pour continuer.
Update to revision
Update to revision peut être fait sur un fichier en particulier, un groupe de fichiers, ou un dossier.
A la découverte d'un bug, on désire parfois repartir d'une version précédente, afin de vérifier le code avant certaines modifications. Au lieu de faire " SVN Update ", il faut alors faure " Tortoise SVN > Update to revision… " et choisir la version désirée.
Diff
Il est parfois intéressant de comparer notre version en cours de développement et la version actuellement sur le serveur. Il existe alors la commande " diff ", qui va afficher une fenêtre de type " winmerge " et afficher les différences entre la version sur votre poste et la version du serveur. On accède à cette fonctionnalité en faisant click-droit sur un fichier, puis " Tortoise SVN > Diff " si le fichier a été modifié, ou " Diff with previous version " si le fichier n'a pas été modifié. Il est alors comparé à la version -1 du serveur.
Commit
Click-droit sur un fichier, un ensemble de fichier ou un répertoire, " SVN Commit ".
Afin que tout le monde bénéficie de la dernière version des sources, il convient de committer régulièrement son travail.
Cependant, les branches et le tronc sont censés être " stable ", afin de ne pas perturber le travail d'une autre personne si elle met à jour.
Il conviendra, dans la mesure du possible :
- De faire un commit quotidien, le soir. Il faudra s'efforcer d'avoir une version qui soit fonctionnelle, même si la fonctionnalité en cours de développement n'est pas terminée.
- De faire un commit après chaque développement, correction, dès que les tests unitaires sont concluants. Si on doit par exemple corriger une faute d'orthographe un mot dans une page (correction de bug), et changer le calcul d'une valeur dans un tableau sur la même page, on fera un commit par modification, puisqu'on aura fait la corrections et l'évolution en deux temps. Ceci permettra de limiter les risques de conflit, et surtout, de tracer plus facilement une éventuelle régression, sans oublier qu'on aura la possibilité de séparer les deux actions, si on doit par exemple mettre en production la correction immédiatement, mais que l'évolution est retardée.
- De faire en même temps un commit de l'ensemble des fichiers concernés par le même développement. Si par exemple, je dois ajouter le nom d'un produit dans une page, je commiterai à la fois la modification dans la feuille XSL, mais aussi le fichier de configuration et éventuellement le fichier de traductions. Ceci afin de grouper au sein d'une même version l'ensemble du développement.
Au moment du commit, si une personne a déjà commité son travail après votre dernier update et avant votre commit, SVN va tenter de corriger automatiquement le conflit (si les fichiers modifiés ne sont pas les mêmes par exemple). S'il n'y parvient pas, il vous affiche un écran du style " winmerge ", et c'est à vous de décider quelles parties du code conserver ou changer.
Revert
Click-droit sur le fichier, un ensemble de fichier ou un répertoire, " Tortoise SVN > Revert "
Il arrive parfois qu'après une modification, plus rien ne fonctionne, ou qu'on se rende compte qu'on s'est trompé de fichier.
Si on désire continuer à travailler à partir de la même version, la suppression du fichier suivit d'un update vous ramènera la dernière version, ce qui n'est pas forcément ce que vous voulez faire. Revert vous permet de revenir à la version d'origine, avant que le fichier ne soit modifié.
La commande blame
Click-droit sur un fichier, " Tortoise SVN > Blame ".
Cette commande vous permet d'afficher le fichier en indiquant ligne par ligne :
- La version de la dernière modification de la ligne
- La dernière personne qui a modifié la ligne
Cette commande est utile lorsqu'après un update, plus rien ne fonctionne, et qu'on cherche à savoir qui a provoqué la régression, afin de comprendre ce qu'il a fait.
Le merge de branche ou la résolution de conflit sont source d'erreurs assez complexes à corriger, et blame est très utile dans ce cas, puisqu'on détecte plus facilement à quelle occasion est apparu la partie du code qui provoque des erreurs.
Création d'une branche
Pour créer une branche à partir d'un dossier projet, il suffit de faire un click droit sur le dossier, puis " Tortoise SVN > Branch/tag ".
Dans la zone " to ", on entre le nom de la branche à créer dans le dossier " branches ".
On indique un commentaire pour donner la raison de création de la branche (typiquement, " Début de l'iWork numéro XXX ").
Création d'un tag
Pour créer un tag, c'est exactement comme pour créer une branche, au détail qu'on crée le tag dans le dossier " tags " et que pour commentaire on indiquera plutôt la date de la livraison.
Récupération d'une branche, d'un tag ou du tronc
Pour travailler sur le code source d'une branche ou d'un tag, on utilisera click-droit " tortoise SVN > Switch ".
Le dossier se mettra à jour avec la version qui se trouve sur la branche ou le tag sélectionné. Pour revenir au tronc, il suffit de choisir le tronc.
Utilisation de lock, unlock et cleanup
SVN gère la concurrence des accès de façon " optimiste ". C'est à dire que lorsque deux personnes désirent travailler sur le même fichier, SVN les laisse faire, et espère qu'elles arriveront à se mettre d'accord pour fusionner leur travail.
Cependant, pour certains fichiers, tels que les fichiers binaires, il est impossible pour SVN de fusionner les modifications.
Dans ce cas, on peut forcer SVN à travailler en mode " pessimiste ".
Il suffit alors de faire un click droit sur le fichier ou le dossier, et faire " Tortoise SVN > Get lock ".
Ainsi, plus personne ne peut faire de modification dans le/les fichiers concernés. Il n'y a plus de conflits possibles.
Lorsqu'on a terminé de faire les modifications, on commit, puis ont faire " Release lock " et ainsi les autres personnes peuvent travailler de nouveau sur le fichier.
Attention cependant, en cas de plantage réseau, ou d'oubli, un lock posé sur un fichier peut être très pénalisant pour tout le monde.
Il faut alors faire " Clean Up ", et SVN va supprimer tous les locks.
La gestion " pessimiste " étant bien moins souple que la gestion " optimiste ", il est conseillé de l'utiliser le moins possible. Pour certains fichiers, cependant, cela peut s'avérer utile (le projet " global " de StreamServe par exemple). On ne posera alors un lock que sur les fichiers qu'on est certain de modifier.
Utilisation sur le serveur Linux
SVN est avant tout un outil en ligne de commande développé pour Unix. Il y a donc un client Linux, utilisable en ligne de commande.
Connaître la version d'un fichier
La commande pour connaître la version d'un fichier est la suivante :
svn info fichier
En réponse, on obtient :
> svn info index.html
Path: index.html
Name: index.html
Working Copy Root Path: C:\GCE160_X
URL:
https://vmcitrix06/svn/GCE160_X/trunk/index.html
Repository Root:
https://vmcitrix06/svn/GCE160_X
Repository UUID: 23628b0a-0b82-2447-8fd8-ae29471086c7
Revision: 152
Node Kind: file
Schedule: normal
Last Changed Author: DEVIDALS
Last Changed Rev: 2
Last Changed Date: 2012-04-12 15:31:48 +0200 (jeu., 12 avr. 2012)
Text Last Updated: 2012-09-07 09:07:34 +0200 (ven., 07 sept. 2012)
Checksum: 3b025ada6a3e16097601d80681e767e4ba9df90f
En rouge : L'adresse du repository. On sait donc ici que le fichier provient du tronc.
En bleu : La version actuelle du fichier.
En rose : La version à laquelle le fichier a été modifié pour la dernière fois.
Ceci veut dire que pour travailler sur la même version en local, il faudra faire un update to revision de la version 152 qui se trouve dans le tronc.
Mettre à jour un fichier à une version précise
La commande pour mettre à jour un fichier à une date précise est la suivante :
svn update fichier -r version
Par exemple :
> svn update index.html -r 2
Updating 'index.html':
At revision 2.
Recherche documentation "complète"
Répondre avec citation
Partager