Subversion - Utilisation et bonnes pratiques

26,486 views

Published on

Présentation de Subversion et de ses bonnes pratiques d'utilisation

Published in: Technology, Business
2 Comments
11 Likes
Statistics
Notes
  • Absolument d'accord, merci
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • super présentation, simple et concise!
    merci!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
26,486
On SlideShare
0
From Embeds
0
Number of Embeds
23
Actions
Shares
0
Downloads
556
Comments
2
Likes
11
Embeds 0
No embeds

No notes for slide

Subversion - Utilisation et bonnes pratiques

  1. 1. TRex Subversion Utilisation et bonnes pratiques Logo client 20/05/2010 +
  2. 2. Présentation Subver... Quoi ?
  3. 3. Subverquoi ? - Présentation de SVN <ul><li>Subversion, un gestionnaire de code source (SCM) et de versionning </li><ul><li>Le versionning permet le travail collaboratif </li></ul></ul>Chacun peut travailler sans écraser les fichiers de son voisin <ul><ul><li>Développement : permet un suivi des sources
  4. 4. Permet de revenir à une version N à un instant T
  5. 5. Permet de comparer les versions d'un fichier afin de voir ce qui a été modifié
  6. 6. Permet de travailler sur plusieurs versions d'un même projet </li><ul><li>Version TMA
  7. 7. Version « future »
  8. 8. R&D sur un projet en cours </li></ul><li>Définition de versions « figées », garanties comme étant stables
  9. 9. Ce n'est pas un système de sauvegarde ! </li></ul><li>Subversion (ou SVN) : un SCM parmi d'autres </li><ul><li>D'autres SCM existent : VSS (Microsoft), ClearCase (IBM), CVS, GIT, Mercurial...
  10. 10. SVN est une évolution de CVS
  11. 11. SVN est Open Source (licence Apache) </li></ul></ul>
  12. 12. Subverquoi ? - Autour du dépôt <ul><li>SVN est un système centralisé </li><ul><li>Centralisation autour d'un « dépôt » ( repository en anglais) pour partager l'information
  13. 13. Le dépôt est un serveur qui stocke toutes les modifications effectuées
  14. 14. Un développeur se connecte en tant que client au dépôt pour récupérer et/ou partager des modifications effectuées sur le dépôt
  15. 15. Le dépôt possède enregistre l'arborescence de fichiers du projet </li></ul><li>Accès au dépôt </li><ul><li>Accès en HTTP essentiellement par l'intermédiaire d'un client SVN
  16. 16. Le client de base est la ligne de commande
  17. 17. Des clients graphiques permettent un accès plus convivial </li><ul><li>Tortoise SVN => Intégration dans l'explorateur Windows
  18. 18. Versions (Mac)
  19. 19. Subversive => Intégration dans Eclipse </li></ul><li>Pour les développeurs, l'utilisation de Subversive dans Eclipse est vivement recommandée ! </li></ul></ul>
  20. 20. Travail collaboratif – Situation à éviter
  21. 21. Travail collaboratif – Avec SVN (1/2)
  22. 22. Travail collaboratif – Avec SVN (1/2)
  23. 23. Organisation & Utilisation
  24. 24. Organisation <ul><li>Trunk, Branches, Tags </li><ul><li>Le Trunk est la ligne de vie du projet. </li><ul><li>« Tronc commun » de développement
  25. 25. Correspond à la version la plus à jour du projet </li></ul><li>Les Branches peuvent correspondre à des « projets dérivés » </li><ul><li>TMA en cours
  26. 26. Projets parallèles
  27. 27. Développements expérimentaux </li></ul><li>Les Tags permettent de « figer » (ou freeze) une version </li><ul><li>Un tag pour chaque version livrée (au minimum !) </li></ul></ul><li>Dépôt SVN bien géré = Projet serein ! </li><ul><li>Possibilité d'automatiser les livraisons (Ant)
  28. 28. Rollback de livraison possible en cas de problème
  29. 29. Historique et organisation clairs pour tout le monde </li></ul></ul>
  30. 30. Utilisation - Commandes <ul><li>Quelques commandes courantes </li><ul><li>svn checkout <URL> <dossier_cible> </li><ul><li>Récupère un projet avec toutes les métadonnées SVN
  31. 31. Indispensable pour commencer à travailler </li></ul><li>svn update </li><ul><li>Met à jour la copie de travail
  32. 32. « Fusionne » les fichiers modifiés
  33. 33. Des conflits peuvent parfois apparaître </li></ul><li>svn commit </li><ul><li>« Propage » les modifications effectuées
  34. 34. Chaque commit correspond à une «  révision  »
  35. 35. TOUJOURS METTRE UN COMMENTAIRE !!! </li></ul><li>svn log </li><ul><li>Affiche l'historique des modifications, révision par révision </li></ul><li>svn revert </li><ul><li>Annule les modifications effectuées sur un fichier et revient à la dernière version (révision) SVN, ou HEAD </li></ul><li>svn merge </li><ul><li>Permet de fusionner des modifications effectuées dans une autre branche que celle de la copie de travail </li></ul></ul></ul>
  36. 36. Utilisation - Conflits <ul><li>Résolution de conflits </li><ul><li>Dans certains cas SVN ne sait pas fusionner lui-même les fichiers sources </li><ul><li>2 développeurs ont modifié la même portion de code => Conflit
  37. 37. Dans ce cas SVN vous laisse la main pour une résolution manuelle </li></ul><li>Pour un fichier monfichier.txt en conflit, 3 sont créés par SVN : </li><ul><li>monfichier.txt.mine => Fichier tel qu'il était dans la copie de travail avant la mise à jour
  38. 38. monfichier.txt.rOLD_REV => Fichier tel qu'il était avant les modifications, dans le dépôt
  39. 39. monfichier.txt.rNEW_REV => Fichier que l'on vient de recevoir du serveur </li></ul><li>monfichier.txt contient des « marqueurs » indiquant où se trouvent les conflits </li><ul><li><<<<<<< .mine (ma modification)
  40. 40. ======= (indique la fin de la modification)
  41. 41. >>>>>>> .rXX (Indique le début du même bout de code à la révision XX) </li></ul><li>Les clients graphiques permettent de visualiser les différences et d'éditer les conflits facilement
  42. 42. Une fois le conflit résolu, il faut : </li><ul><li>Signaler la résolution du conflit (svn resolved)
  43. 43. Commit le fichier avec le conflit résolu </li></ul></ul><li>Important !!! </li><ul><li>TOUJOURS résoudre les conflits en cours
  44. 44. NE JAMAIS COMMIT DES FICHIERS EN CONFLIT NON RESOLU !!! </li></ul></ul>
  45. 45. Utilisation - Conflits
  46. 46. Utilisation - Propriétés <ul><li>Les propriétés sont des « méta-données » </li><ul><li>Elles permettent de modifier le comportement standard de SVN
  47. 47. La plupart sont destinées au fonctionnement interne de SVN
  48. 48. Certaines peuvent être très utiles </li></ul><li>svn:ignore </li><ul><li>Permet d'ignorer un certain nombre de fichiers par emplacement ou pattern (Thumbs.db, cache, logs...)
  49. 49. A régler au début d'un projet pour éviter de versionner des fichiers inutiles </li></ul><li>svn:externals </li><ul><li>Permet d'indiquer une dépendance
  50. 50. Par exemple une librairie maintenue par une autre équipe </li><ul><li>Inutile de dupliquer le code dans le dépôt
  51. 51. S'il y a des mises à jour dans le dépôt défini en svn:externals, votre copie de travail sera également mise à jour lors de votre prochain update
  52. 52. Utilisé souvent avec Symfony pour récupérer le kernel du framework </li></ul></ul></ul>
  53. 53. Comprendre les branches
  54. 54. Des branches : Pour quoi faire ? <ul><li>Maintenance </li><ul><li>Une branche est souvent une « copie » du trunk (répertoire principal) </li><ul><li>Ligne de vie indépendante
  55. 55. Historique commun => Permet les fusions </li></ul><li>Exemple sur un projet web avec TMA + Evolutions </li><ul><li>Les évolutions sont développés sur le trunk (future release)
  56. 56. Mais des bugs peuvent être signalés en production et doivent être corrigés
  57. 57. => Création d'une branche pour la TMA (correction de bugs uniquement)
  58. 58. => Livraisons effectuées à partir de la branche TMA
  59. 59. => Une fois les bugs corrigés, on fusionne les correctifs avec le trunk </li></ul></ul></ul>
  60. 60. Fusion entre branches (Merge) <ul><li>Pourquoi fusionner (ou « merger ») ? </li><ul><li>Permet de maintenir les branches à jour entre elles
  61. 61. Évite de modifier 2 fois du code source (branche TMA + Trunk) </li><ul><li>La multiple modification manuelle présente des risques de régressions
  62. 62. SVN fusionne intelligemment (par différentiel) </li></ul></ul><li>Comment faire ? </li><ul><li>Pré-requis </li><ul><li>Pour fusionner entre 2 branches il faut avoir les 2 copies de travail en local
  63. 63. Les 2 copies doivent être à jour </li></ul><li>Modification du code source sur la branche TMA </li><ul><li>svn commit -m 'Correction de bug #123' mondossier/monfichier.php </li></ul><li>Fusion dans la copie de travail du trunk, d'abord en local </li><ul><li>cd /chemin/vers/trunk/working/copy
  64. 64. svn merge http://mon-repository-svn/monprojet/branches/tma/mondossier/monfichier.php mondossier/monfichier.php
  65. 65. On teste que tout fonctionne, puis on commit
  66. 66. svn commit -m 'Merge correction de bug #123' mondossier/monfichier.php </li></ul><li>Des conflits peuvent survenir avec le merge, comme avec un update. Il faut dans ce cas les résoudre avant de commit
  67. 67. Vous pouvez vous rendre compte des modifications (et donc conflits potentiels) en passant l'option « dry-run » à la commande de merge </li><ul><li>svn merge http://mon-repository-svn/monprojet/branches/tma/mondossier/monfichier.php mondossier/monfichier.php --dry-run </li></ul></ul></ul>
  68. 68. Intégration à Eclipse
  69. 69. Plugins Eclipse <ul><li>Une fonctionnalité : 2 plugins </li><ul><li>Subclipse </li><ul><li>Client SVN historique dans Eclipse
  70. 70. Maintenu par Tigris, l'équipe de développement de SVN
  71. 71. Open Source </li></ul><li>Subversive </li><ul><li>Client retenu par la fondation Eclipse
  72. 72. Initialement développé par la société Polarion
  73. 73. Open Source </li></ul></ul><li>Il ne peut en rester qu'un ! => Subversive </li><ul><li>Plus stable que son concurrent
  74. 74. Bien documenté dans l'aide d'Eclipse
  75. 75. Présent dans les paquets optionnels de Galileo (Eclipse 3.5) </li></ul></ul>
  76. 76. Subversive : Présentation
  77. 77. Subversive - Présentation <ul><li>S'intègre parfaitement à votre « workspace »
  78. 78. Compatible avec la fonction de synchronisation d'équipe </li><ul><li>Permet d'anticiper les mises à jour et les conflits à venir </li><ul><li>Présentation visuelle des modifications entrantes et sortantes
  79. 79. Possibilité d'afficher les différences sur ces modifications </li></ul><li>Accessible depuis le menu contextuel (Team / Synchronize) </li></ul></ul>
  80. 80. Autres clients SVN <ul><li>Tortoise SVN (Windows, intégration dans l'explorateur) - Gratuit
  81. 81. SCPlugin (Mac OS, intégration dans le Finder) - Gratuit
  82. 82. Rapid SVN (Java, vieillissant) - Gratuit
  83. 83. Versions (Mac OS) - Payant
  84. 84. SVNx (Mac OS, vieillissant) - Gratuit
  85. 85. RabbitVCS (Linux – Gnome, intégration dans Nautilus)
  86. 86. KDESVN (Linux – KDE, intégration dans Konqueror) </li></ul>
  87. 87. Conclusion <ul><li>SVN est un puissant outil de gestion de versions
  88. 88. Indispensable pour le développement en équipe, voire seul !
  89. 89. SVN n'est pas un système de sauvegarde !
  90. 90. Permet un suivi de versions précis, à condition de bien l'utiliser
  91. 91. Ce n'est pas le seul SCM du marché ! </li><ul><li>GIT gagne de plus en plus terrain (nouvelle génération, décentralisé...) </li></ul><li>De nombreuses intégrations (IDE, clients indépendants) sur toutes les plateformes </li></ul>
  92. 92. Des Questions ? ?

×