novembre
2008
Un article de tanek
Depuis un moment déjà, on commence à parler de systèmes de contrôle de version décentralisés, une expression bien barbare pour finalement quelque chose de très simple et très puissant. Je ne vais pas vous apprendre à l’utiliser mais plutôt vous donner un problème de développement logiciel qui a pu être résolu grâce à cette technologie. Pour tout ce qui est pratique je vous redirige vers ce tutoriel très bien fait :
http://www.eleves.ens.fr/home/oudomphe/comp/ware/git.xhtml.fr
Venons-en maintenant au problème :
Je devais migrer une application d’une bibliothèque de visualisation 3D vers une autre bibliothèque. C’est donc quelque chose de très lourd à mettre en place, qui demande une réécriture importante du programme et surtout, implique que le programme ne marchera pas pendant un petit moment. Le seul soucis est que je devais faire ça en parallèle avec un autre programmeur qui lui travaillait plutôt sur la partie données du programme. J’avais pour consignes de ne pas le déranger dans son travail car il devait fournir un prototype dans le mois qui arrivait et donc je ne devais pas casser le programme.
La gestion des versions était géré par le système SVN. SVN permet de résoudre ce problème avec le mécanisme des branches. Je travaille sur ma branche, l’autre programmeur sur la sienne et une fois que j’ai terminé la migration, on fusionne les deux branches. Le problème avec cela est qu’il va y avoir beaucoup de conflits entre les deux branches et ceci va être très long à corriger. De plus il peut se poser d’autres problèmes. Par exemple, imaginons qu’il ait fait un refactoring, j’aurais continué mon développement sur l’ancienne version et donc il aurait fallu réécrire une bonne partie de mon code pour l’adapter à la nouvelle conception (j’ai en somme écris du code pour rien). La solution consistait à fusionner les deux branches régulièrement mais ceci est un processus assez long.
C’est là que nous avons introduit git et son interface SVN git-svn qui permet de faire le pont entre les deux technologies. git est un système de contrôle de version mais contrairement à SVN qui est un système centralisé (un dépôt pour tous les programmeurs), ce dernier est décentralisé. Cela veut dire qu’il peut exister un dépôt principal, mais chaque programmeur peut avoir son propre dépôt sur sa machine et le mettre à jour par rapport à un autre dépôt et ceci de façon automatique.
Qu’est-ce que cela veut dire pour nous ? Et bien je pouvais travailler sur ma version du programme, faire des sauvegarde régulièrement pour contrôler mon développement sans que cela n’interfère avec l’autre programmeur puisque je faisais les sauvegardes sur mon dépôt. De plus je pouvais mettre à jour mes versions avec une simple ligne de commande et cette dernière fusionnait automatiquement ma version avec la version de mon collègue en gérant tous les conflits (car il gardait en mémoire comment j’avais résolu les anciens conflits, je ne devais donc gérer que les nouveaux conflits au lieu de les gérer tous d’un coup). De plus je pouvais passer de sa version à la mienne en moins de cinq secondes, ce qui n’est vraiment pas aussi rapide avec subversion…
Grâce à cela j’ai donc gagné énormément de temps lors de la fusion des versions vu que le travail avait été effectué au fur et à mesure. Git est donc très adapté pour ce genre de problème, bien plus que les branches de subversion.
J’ai utilisé également un autre outil au dessus de git pour un autre problème : la gestion d’une pile de patchs sur une bibliothèque. Ca s’appelle stgit et vous avez une petite introduction ici :
http://git.or.cz/course/stgit.html
Bonne lecture !
Merci pour cet explication
Malheureusement le lien vers le tuto n’existe plus
Bonne continuation