Gérer une communauté de développeurs, les bonnes raisons pour quitter SVN

Comme vous le savez, je suis assez actif sur le projet Open-source du Bilboplanet qui est un CMS de planet développé en PHP et qui se veut devenir une référence pour la création de planets, au même titre que wordpress et dotclear sont devenus une référence pour créer des blogs. C'est donc en me basant sur cette expérience et mes différentes expériences professionnelles que j'aborde ce sujet épineux (troll?) qui est de se poser la question par rapport à la pertinence du gestionnaire de version Subversion par rapport à ce qui existe d'autre sur le marché.

Je ne connais évidement pas tous les systèmes de versionning existant. Et j'en ai encore utilisé moins. Mais voici un petit topo de mon expérience dans le domaine :

• Subversion : Je connais et j'ai beaucoup utilisé, et dans tous les sens (sorti en 2000)
• Git : je connais et j'ai beaucoup utilisé (sorti en 2005)
• Bazaar : je connais et j'ai déjà pas mal utilisé (j'irais pas jusqu'à dire que je maitrise bien le bazaar ^^) (sorti en 2004)
• Mercurial : je sais comment ça marche en théorie, mais j'ai jamais utilisé (sorti en 2005)
• CVS : je sais comment ça marche en théorie, mais j'ai jamais été plus loin (sorti en 1986)

D'un point de vue fonctionnement on peut vite mettre tous ces gestionnaires de version dans 3 catégories bien distinctes :

• Système centralisé sur le réseau : subversion
• Système décentralisé sur le réseau : Git, Bazaar, Mercurial
• Système décentralisé sur fichiers : CVS

Je ne vais pas m'attarder sur CVS qui est le plus vieux d'entre tous et qui a malgré tout aussi les faiblesses de son temps. Mais je trouvais néanmoins qu'il était intéressant de le citer et de le resituer dans le temps pour plus de clarté. Il va de soi qu'il faut en tenir compte car ça a influencé le choix des technologies utilisées. En effet, si en 1986 on n'a pas fait un système basé sur le réseau, c'est aussi parce que le réseau en était qu'à ses débuts à cette époque là. Si subversion s'est mis en place sur un système centralisé, c'est parce qu'en 2000 on n'imaginait pas encore la puissance qu'on pouvait trouver dans la décentralisation des données, etc.

Les avantages de SVN

Si le projet du Bilboplanet utilise SVN, si google-code utilise SVN, si sourceforge utilise SVN, c'est pas pour rien ! Subversion propose clairement des avantages qui sont indéniables et qu'il faut souligner. Indépendamment du fait qu'il permet effectivement de résoudre les conflits (c'est la moindre des choses car c'est bien son but initial) il apporte pas mal d'avantages.

Tout d'abord insistons sur sa facilité d'utilisation. En effet, inutile de passer 8h le nez dans un manuel pour comprendre comment fonctionne subversion. D'ailleurs même visuellement il est très facile de faire un schéma car on voit très vite comment ça marche :

• Un serveur : avec une version toujours à jour
• Plusieurs clients qui commitent de temps en temps du code

C'est un avantage indéniable que d'avoir un système aussi simple.

Un autre avantage qui découle de sa simplicité est son workflow qui est totalement trivial. En effet (à moins de faire de la duplication de code dans tous les sens et d'essayer de faire des branches avec svn) l'utilisation normale de SVN amène directement à un fonctionnement tout à fait simple :

1. On checkout pour avoir une copie en local
2. Avant de coder on fait un update
3. On modifie le code
4. Avant de commiter on fait un update pour résoudre les conflits éventuels
5. On commit nos modifications

C'est donc facile, tout le monde a une copie du code et peut commiter quand il le souhaite.

Ce qu'on aime bien aussi c'est le fait qu'il n'y ai qu'un seul endroit où il y a un code à jour. Cet endroit est le serveur et ainsi on n'a pas de confusion possible. En effet, un système comme CVS pouvait évoluer de plusieurs manières différentes en parallèle et il devenait difficile de savoir quelle était la version la plus évoluée. Un réel "merge" était nécessaire pour créer une version finale.

Et puis, rien à faire, subversion est tellement utilisé que les gens l'aiment bien ! Pas besoin de ré-apprendre un nouveau truc, on connait et on sait comment ça marche. Pour certains développeurs c'est clairement un avantage. Mais il y a aussi l'effet pervers qui en découle, car le développeur qui ne veut pas se former et se mettre à jour avec les nouvelles technologies est voué à avoir des problèmes à l'avenir (surtout dans le domaine de l'informatique ou tout évolue très vite).

Les faiblesses de SVN

Mon but est évidement de vous montrer que SVN est un système de versionning moins puissant que les systèmes décentralisés. Voyons donc pourquoi svn a des lacunes et qu'est-ce que les autres systèmes proposent comme solutions à ces problèmes.

Tout d'abord parlons justement de cette centralisation des données sur laquelle est basée SVN. En effet, si le serveur tombe en panne, comment faire pour récupérer les données? Eh bien ça n'est pas possible. Vous aurez évidement votre version en local, mais vous ne pourrez plus rien faire avec. Et impossible de la merger avec un autre instance sur un autre ordinateur. Vous devrez donc refaire un nouveau serveur, ré-importer les données et ainsi perdre beaucoup de temps. Mais vous allez aussi perdre tout l'historique de vos modifications. Ce qui n'est pas vraiment pratique et qui peut même parfois être dangereux car vous risquez de passer à coté de certains conflits!

Un autre problème évident apparaît lorsqu'une nouvelle personne rejoint l'équipe de développeurs sur le SVN. C'est évidement surtout vrai dans une communauté open-source où on n'a pas toujours l'occasion de faire la connaissance de la personne avant de l'ajouter au groupe. Viennent donc les questions de base : sait-il résourdre un conflit sur SVN? Est-il un bon développeur? Ne vas-t-il pas foutre en l'air le code qui se trouve sur le repository? Vas-t-il respecter les règles de code qu'on s'est fixées? Bref, il peut arriver que le nouvel arrivant ne soit pas un "topgun" comme vous et foute en l'air votre code. A ce moment là vous allez être bien embêté. L'avantage de SVN est évidement de vous "garder un backup" de vos anciennes modifications, mais c'est pas pour autant qu'il va être facile de les récupérer tout en gardant malgré tout le travail du petit nouveau qui a un certain intérêt (et qu'on ne voudrais pas vexer).

Il faudrait donc revenir en arrière, faire des modifs, puis revenir en avant. C'est vite une grosse manipulation car on n'a qu'une seule ligne du temps. Et si vous voulez encore plus vous compliquer la vie : imaginez que pendant que vous manipuler la ligne du temps, un autre urluberlu vienne faire un nouveau commit ! Je vous parie une bière que vous allez passer au moins 1h à vous prendre la tête sur la correction du code !

Un autre exemple qui va vous parler: vous coder en utf8 et votre "petit nouveaux" code en ASCII car il n'a pas configuré son editeur de texte comme vous. Vous allez vous retrouver avec des encodages différents dans tous les sens, et il faudra revenir en arrière, sans pour autant enlever les modifs faites car elle avaient du sens.

Dans la série des exemples, il y en a beaucoup. Mais prenons le cas d'un utilisateur qui oublie d'ajouter un fichier lors de son commit. Il va donc devoir faire un 2ième commit avec le même message car c'est un commit pour la même chose. Si vous retourner voir votre historique 6 mois plus tard, c'est pas sur que vous puissiez vous y retrouver dans les 10 commits qui concernent la même fonctionnalité !

Un autre inconvénient évident c'est que pour SVN vous devez travailler dans un environnement où vous avez accès au serveur. Sinon impossible de découper vos commits correctement en fonction de la tâche sur laquelle vous bossez. Or pour commiter vous devez avoir accès au serveur qui ne l'est pas toujours (on n'a pas toujours internet, on n'a pas toujours accès au serveur de l'entreprise, ...)

Pour SVN si on veut éviter un maximum les problèmes, il faut faire un accès restreint avec mot de passe. En effet, comme je l'ai expliqué plus haut, si n'importe qui décide de commiter n'importe quoi, on se retrouve vite avec des problèmes. D'où l'intérêt de limite l'accès en écriture. Mais c'est aussi un désavantage à mon sens. Car si on veut ajouter quelqu'un il faut lui faire des accès : ce qui nécessite des connaissance en administration (et donc que l'administrateur soit disponible). De plus, on doit faire confiance au nouveau venir "à priori" car on n'a pas encore vu le genre de code qu'il écrit et on ne connait pas ses intentions. Pour l'utilisateur extérieur c'est d'ailleurs aussi une contrainte car ça lui demande de prendre contact avec l'équipe de développeurs et donc de faire des démarches. (ceci n'est pas le cas dans les systèmes décentralisés)

Conclusion

Subversion est victime de sa simplicité d'utilisation. En effet, une mauvaise utilisation peut vite mener à une perte de temps, une perte d'efficacité et peu de consistance. A moins d'avoir une petite communauté de développeurs et des développeurs qui suivent tous les bonnes pratiques à la lettre.

Voyons maintenant ce que des systèmes décentralisés tels que Git ou Bzr apportent

Je vais vous parler de ces 2 systèmes car je les connais tous les deux et ils apportent, dans les grandes lignes en tout cas, des fonctionnalités équivalentes (bien qu'ils aient des différences, il faut le dire).

L'avantage d'un système décentralisé est avant tout qu'il est décentralisé. On n'a donc pas besoin d'être connecté à un serveur pour pouvoir travailler sur son code et faire ses commits. Par définition on fonctionne donc sur un système de "branching" (branches) qui est assez simple : Toute personne qui travaille sur un code travaille sur une branche du code. Il est donc indépendant du tronc commun et fait "ce qu'il veut" avec le code.

L'utilisation de ces sytèmes demande donc évidement d'avoir une personne centrale qui s'occupe de gérer le tronc. Cette personne est nommée "responsable" et en général c'est une personne de confiance qui s'en occupe. Ceci afin de s'assurer que le code du tronc commun soit toujours stable et en évolution ! Ca permet donc à n'importe qui de venir se greffer au tronc car il a la certitude de se greffer à quelque chose de stable. En effet, c'est l'essence même du système : le tronc ne doit jamais être instable.

Mais alors comment le faire évoluer? Eh bien chaque contributeur développe sa branche. Il peut même bosser sur plusieurs tâches. Chaque fois il commit ses modifications (sur sa branche) et avance petit à petit. De manière régulière, quand ce dernier estime que sa branche est stable, il demande au responsable du tronc de "merger" sa branche. Ce dernier peut donc merger la branche et le développeur repart du tronc pour faire une nouvelle branche. La seule contrainte est qu'il ne faut pas que la branche devienne trop grande. Car sinon le merge devient lourd et difficile. Il est donc important que le développeur merge sa branche dès qu'il a quelque chose de stable et qu'ensuite il reparte depuis le tronc.

On peut vraiment visualiser le fonctionnement comme un arbre. C'est exactement ce principe là. (Dans l'image ci-dessous le tronc est à droite et s'appelle "master")

Le gros avantage c'est que n'importe qui peut se greffer sur le projet. Même si un illustre inconnu crée sa branche, il n'a pas d'influence sur le projet tant qu'il ne demande pas au responsable du tronc de merger sa branche. Et s'il le fait, le responsable du tronc peut lire le code de l'inconnu et estimer de sa pertinence pour le projet. Et en fonction de sa qualité, l'accepter, le rejeter ou demander des améliorations. Il est donc beaucoup plus facile pour les extérieurs de participer au projet sans aucune démarche préalable nécessaire. Il n'est même pas obligatoire de prendre contact avec les développeurs principaux du projet. C'est tout à fait facultatif.

Concernant les défauts liés à l'historique de SVN dont je parlais plus haut. Ici l'historique du tronc est géré par le responsable du tronc. Comme cette personne est une personne de confiance qui sait ce qu'elle fait, on peut espérer que l'historique du projet soit donc clair et bien organisé afin de permettre une bonne visibilité pour les autres contributeurs du projet.

Mais il faut avouer que l'inconvénient de ces système décentralisés est qu'ils apportent un peu de complexité. C'est donc un peu plus compliqué à utiliser que subversion. Mais ça apporte tellement d'avantages que ça vaut la peine de faire le pas.

Convaincu? Alors essayez !

De plus en plus de projets Open-source passent à Git ou à Bzr actuellement. Il faut dire que l'interface Launchpad prend de l'importance et fonctionne avec Bzr et d'autre part Gitorious et Github sont aussi fortement utilisés. Il faut dire que Git a été développé par Linus Torvalds dans le but de servir pour le développement du noyau Linux et Bzr a été développé par Canonical pour le développement d'Ubuntu. Ils ont donc tous les deux été pensés pour le logiciel libre et sont donc parfaitement adapté à sa philosophie.

N'hésitez pas à partager vos expériences et vos avis dans les commentaires de ce blog. Je ne considère pas que je détient LA vérité en la matière. Je vous partage juste mon impression liée à mon expérience. Je vous invite donc, vous aussi, à me faire part de vos impressions et de vos avis (le troll est lâché).